Subject: Re: [boost] [operators] A modern SFINAE-based version of boost::operators?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-11-19 22:51:54
Le 19/11/2017 à 06:22, David Stone via Boost a écrit :
> Here is the initial wording of my proposal for the C++ standardization
> committee on generating more operators by default. I welcome any feedback.
> I intend to present this at the next meeting in March.
>
> https://github.com/davidstone/isocpp/blob/master/generate-operators.md
Hi David, thanks for sharing.
I believe that we shouldn't generate operations individually. We could
generate some operations given a minimal definition set for a specific
concept.
As you note on your paper C++ operators are overloaded on different
concepts. We need the concept in order to know what do we want to generate.
I have a lot of cases where operator += must be derived of operator+.
But I have also cases where the compiler could generate an optimal code
defining operator + in function of operator+=. When we define operator
+, very often we want also operator++. And sometime we don't want it.
I'm not for having a language that generates more functions by default
without opt-in. It is quite complex for a lot of people to imagine what
they don't see.
I want to see in the code that we are asking for the derivation of some
operations given we provide some other. This is what Haskell deriving
construct is for. With Template Haskell you can describe how this
operation are derived. This is something we could have with the current
direction of meta programming.
I believe the paper is missing concrete examples that could apply to the
standard, and seen the operators that could be derived in each case and
with which semantic.
I agree with the comments of Daniel Frey. operator+ for strings i snot
the good example, as it is not commutative.
see operator++ as x+= 1 need a value 1 and seen -a as 0 - a needs a
value 0. These have a sense on certain kind of types. So the solution
consists in identifying the kind of types where this could be applied.
|a - b| is theoretically equivalent to |a + -b only when b define -b
without overflow, isn't it?
Could you elaborate on the following sentence
"||Even if that negation is well defined, there still may be overflow;
consider |ptr - 1U|: we rewrote that to be |ptr + -1U|, the pointer
arithmetic would overflow."
|Could you show some examples (in the standard) where seen |lhs->rhs| as
|(*lhs).rhs would reduce the standard wording? Some additional
non-standard examples?|
I don't see a flat map as a random access container, but maybe I'm
missing something evident.
Note that operator <=> return type implies the operation we want to
derive and its implementation. While I find the approach interesting, I
believe also it is a hack, it doesn't scale. We need a more generic
mechanism to generate operations.
On what concern the original post, and waiting for meta in the language
(reflection/reification), we can define those using CRTP in Boost. But I
will be against doing it without associating them to a concept.
If we replace the spaceship operator <==> by a `order::compare` function
we are able to define using CRTP the associated operations. We don't
need a language change.
Best,
Vicente