It's an interesting idea. Perhaps it needn't be a change, but an addition -
allow one or the other. I'm not sure if it's solving a major problem, but
the whole fake int parameter bodge is certainly a slight annoyance.

Im against using "this" though. "this" is a pointer and I believe it might
confuse people to have a syntax that *almost* looks like a pointer
increment but actually defines a custom increment on the object. If we had
a keyword that mapped to (*this), E.g. Python's "self", I'd choose that
keyword instead.


On Thu, 17 Oct 2019, 09:50 John McFarlane via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Wed, 16 Oct 2019 at 07:30, Andrew Tomazos via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> 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.
>>
>
> I agree that this is an ambitious change. I do like the syntax a lot more
> than the existing, though.
>
> For friends, could you / would you be able to specify a friend WRT a
> specific parameter?
>
> e.g.
>
> friend auto operator this + (bar); // friend when this is LHS
>
>>
>> On Wed, Oct 16, 2019 at 3:55 PM John via Std-Proposals <
>> std-proposals_at_[hidden]> 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_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>