Re: [boost] [type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.

Subject: Re: [boost] [type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-24 12:18:39

2011/3/24 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>>
>> Comparing the names I tried to find "Most Unifying Proposals" for
>> names in column MUP:
>>
>> https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
>
> The summary table was helpful, Joachim.  Thanks.
>
> Names in the standard are certainly appropriate candidates for
> use in the Type Traits library,

> even if I would rather the standard's names were different.

[Non native speaker questions] Is this expression colloquial? Does it
mean you wish the standard's names were different?

>
> I have some quibbles with your MUP choices, though.
> For example, you cite std::plus, minus, multiplies, and divides
> as naming examples from the standard,

I was thinking about you, when I saw them, they're pretty
inconsistent, aren't they?

> yet those are the names of function objects, not of operators.

true

> Given that Proto uses those names for the operators, there's
> some precedence for applying them in the traits, but I'd still
> prefer "addition," "subtraction," "multiplication," and "division"

ahh, a much more consistent naming :)

> as the traits names.  For brevity, and to more closely match
> the corresponding concept names,
> "add," "subtract," "multiply," and "divide" would be acceptable.

I agree these names are nicer as those chosen by the standard and proto ...

Still

(1) I would prefer uniformity over improvement here. I think it is of
greater value, if we manage to converge names in boost and the
standard, specifically in fields that are very fundamental to c++ as a
language, which is clearly the case here.

(2) If we considered to choose new names, I'd clearly prefer names
that emphasize on syntax, to make clear that semantics is attached to
operators by implementation

 sign   semantics
+ cross  addition, set union, concatenation, ...
- dash   subtraction, set difference, deletion ...
* star   multiplication, intersection, Cartesian product ...
/ slash  division, factorization, ...

> Similarly, you used the function objects from the C++0x
> standard as the basis to justify "bit_and," "bit_or," and "bit_xor."
> Proto uses the better "bitwise_*" forms for the operators.

Those three are a proposed addition to the new upcoming standard, all
the others are in the current standard already.

Maybe this mail
http://www.mail-archive.com/[e-mail]/msg07394.html
was the cause of their naming and appearance in the new standard.

But from a wider perspective of maximizing naming consistency in boost
and the standards, I think
bitwise_* would
be wise ;-)

Also it'd be better to implement those functors completely (for all
possible operators) and in their most general form e.g.

template<class T, class U=T, class R=T>
struct a_binary_op; // instead of

template<class T>struct a_binary_op;

which is in the current proposal.

> Editorial comments:
>
>  - For others just reading the table, putting "logical_not" with the other "logical_*" entries would be, well, logical

In order to be "most helpful" I chose the sequence found in Frédéric's
docs that seem to be odered by arity.

In the long run I'd prefer to order according to precedences, which is
probably the most useful ordering for users.

>  - Similarly, putting pre- and post-increment and decrement together would be helpful
>
>  - In the legend: s/MPU/MUP/
done.

If we can reach an agreement among boosters quickly we might be able
to influence the standard now. Otherwise we'd have to wait for another
decade :-/

Thanks
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de