Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-04-30 10:49:35
2011/4/29 Joachim Faulhaber <afojgo_at_[hidden]>:
> 2011/4/29 Gottlob Frege <gottlobfrege_at_[hidden]>:
>> On Thu, Apr 28, 2011 at 10:27 PM, Joseph Wu <josephclwu_at_[hidden]> wrote:
>>> On 04/28/2011 07:57 PM, Joachim Faulhaber wrote:
>>>> To save you some time, I have inserted my proposal as column D into the
>>>> Wiki at
>>> +1 for column D
>> I think (in order of strength of my opinion)
>> - naming is very important
>> - plus-equal (et al) is better than any of the other options
> interesting ...
> ... could you give us a deeper insight in the superiority of this
> particular name?
I'm still wondering about your preference for "plus_equal". My own
considerations here are these:
I remember a lecture by my professor in compiler construction two
decades ago, who raged against the use of operator = in c. I'd be
stupid to assign the assignment semantics to an operator = that is
used in maths with a semantics of "is equal to" for centuries. He
preferred to use := for assignment and = for equality. I agreed with
him then and I still agree today.
Alas ranting and raving of professors didn't influence c: Operator =
is associated to assignment and operator == is associated to equality.
And because we were drilled differently in maths, one of the most
frequent error amongst c-novices was buried in code like
that led to seemingly bizarre behavior, both on the program's and on
the programmer's part.
Once attached to the = sign, the assignment semantics is used
consistently in c and later c++
x += y for x = x + y
assign after plus. In contrast to
x +:= y for x := x + y
in the family of algol languages.
Similar for other operations o
x o= y for x = x o y
This perfectly justifies
plus_assign for +=
if + is named plus and
= is named assign
at least I think so ...
-- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk