Date: Thu, 17 Oct 2019 09:49:56 +0100
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_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
>
Received on 2019-10-17 03:52:21