Re: [boost] [operators] A modern SFINAE-based version of boost::operators?

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