On 8/30/2020 12:35 AM, Jeremy Ong via Std-Discussion wrote:
> Perhaps a type trait is a suitable alternative for this (as opposed to
> introducing yet another keyword that decorates a function signature). For
> example: https://godbolt.org/z/ecaro9

+1

Also use std::enable_if instead of a static_assert in the function body.
  This takes advantage of SFINAE so that you can write `does_commute`
for some types, `does_anticommute` for other types, etc.

https://godbolt.org/z/7ssTjW

>
> On Sat, Aug 29, 2020 at 6:03 PM Tobias W. via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> Hi everyone!
>> I am coming with a mathematical and embedded systems background and
>> there is something that bothered me since I started programming.
>> Firstly, I would like to explain the problem with an example that occurs
>> often in slightly different but similar ways.
>> Secondly, I will propose a possible solution.
>> Of course, I would love to hear your thoughts.
>> So let's imagine we have three classes.
>> class Real{
>> double value;
>> ...
>>
>> };
>>
>> class Imag{
>> double value;
>> ...
>>
>> }
>>
>> class Complex{
>> double Im;
>> double Re;
>> ...
>>
>> };
>>
>> Then if I was to write functions, for example, an add function or
>> operator+ and would like to add them in all possible permutations of
>> arguments.
>> This means, that I would have to write all those following functions,
>> just to add them:
>>
>> Complex operator+ (Real a, Imag b);
>> Complex operator+ (Imag b, Real a); // Mirrored function
>> Complex operator+ (Real a, Complex b);
>> Complex operator+ ( Complex b, Real a); //Mirrored function
>> Complex operator+ (Imag a, Complex b);
>> Complex operator+ ( Complex b, Imag a); //Mirrored function
>>
>> From a mathematical point of view, all mirrored functions are obsolete,
>> because the intent has already been stated in the function above.
>> Furthermore, each mirrored function will use additional program memory
>> and this can become an issue on embedded devices.
>> Therefore I would like to introduce the idea of the expression
>> "commutative" that can be added to functions.
>> The commutative expression will tell the compiler that he can switch the
>> parameters that will be passed to a function.
>> Following this, the keyword will only be allowed for functions that
>> possess two and only two parameters.
>> Then the example from above may look something like this:
>>
>> commutative Complex operator+ (Real a, Imag b);
>> commutative Complex operator+ (Real a, Complex b);
>> commutative Complex operator+ (Imag a, Complex b);
>>
>> If the compiler comes across a statement like below, he is allowed to
>> restructure the code.
>>
>> Complex = Complex * Imag + Real;
>>
>> will change to:
>>
>> Complex = Real + Imag * Complex;
>>
>> and now the three commutative functions can be used to process this
>> command.
>>
>> This is far less to write, the intent is clear, fewer functions are used
>> and I only pay for the programme memory I need.
>> This, of course, is not allowed to change the evaluation order of
>> operator* and operator+. The operator* will always be evaluated first
>> and the operator+ will always work with its result.
>> The operator+ is not allowed to steal one of the operator* 's parameters.
>> commutative will, of course, be available for all functions that take 2
>> parameters, not just operators.
>>
>> These are my thoughts, as already stated above, I would love to hear yours.
>>
>> Sincerely,
>> Tobias Wallner
>>
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
>
>