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