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

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
>