While it may be agreed that your new syntax is better, we would need to keep the old syntax as well to avoid breaking existing code.  That given, I don't think the new syntax is so much better than the old one that it warrants creating two different ways to declare the same operators.  Keep in mind that having two ways would mean everyone would have to learn both ways in order to be able to read code.

On Wed, Oct 16, 2019 at 3:55 PM John via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I have thought of an improved syntax for member operators, which as I
will hopefully demonstrate:
* is clear, consistent, and intuitive
* is quickly learned by novices and experts alike
* allows most developers to forget the entire concept of dummy
parameters for postfix increment and decrement (compiler developers
are sadly exempted)
* allows most binary operators to be defined on either the left side
type or the right side type, thus allowing e.g. member stream
insertion operators
* does not conflict with existing or planned C++ syntax, and
* is actually a fairly small change in syntax

I look forward to hearing about everything I have overlooked. : P

For member operator declaration/definition, the new syntax can be
constructed from the current syntax by removing the dummy parameter
(if any) and inserting the keyword "this" either before or after the
operator name, whichever side the defining object would need to be on
for the operator to be invoked using operator syntax.

Examples using current syntax:

ResultType operator + (RightSideType);
ResultType operator ++ ();
ResultType operator ++ (int);

Same examples using new syntax:

ResultType operator this+ (RightSideType);
ResultType operator ++this ();
ResultType operator this++ ();

Note that each of the new syntax examples is considered to be the same
operator as the corresponding current syntax example. In particular,
postfix increment and decrement still take a dummy parameter, but that
parameter may not appear in the operator declaration or be referenced
within the function body when using the new syntax. It is an error to
define the same operator using both syntaxes, just as it would be an
error to define the operator twice using the same syntax. However, it
is perfectly legal to declare the operator using one syntax and then
define it with the other.

Also note that this syntax allows operators to be declared on the
right side type rather than the left side type. Compare the following
declarations for a member bitshift operator and a member stream
insertion operator:

ResultType operator this<< (int NumberOfBits);
std::ostream & operator <<this (std::ostream &);

Finally, for completeness, function call syntax is extended to handle
the new operator syntax. Because an operator declared using the
current syntax is the same operator when declared using the new
syntax, it should be possible to call any operator using either
syntax, regardless of how it was declared. Also note that, when
postfix increment or decrement is invoked using the new syntax, the
dummy parameter is considered to be defaulted (int whatever = 0) and
thus does not need to be specified in the call. This default obviously
does not apply when the operator is invoked using the current syntax,
as it would reintroduce the very ambiguity in the old syntax that the
dummy parameter was created to eliminate.

Function-style invocations using current syntax:

foo.operator +(bar);
foo.operator ++();
foo.operator ++(0);

Same invocations using new syntax:

foo.operator this+(bar);
foo.operator++this();
foo.operator this++(); // or foo.operator this++(0);

Function-style invocation of that new member stream insertion operator:

foo.operator<<this(std::cout);

In all cases, the new syntax depends on insertion of the keyword
"this" in a context where I do not believe it could have ever legally
been used before, or to my knowledge has been planned to be allowed in
the future, so this new syntax shouldn't conflict with anything else.

Feedback is greatly appreciated.

Regards,

John
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals