Date: Fri, 18 Oct 2019 15:03:14 -0700
I dare suggest that the major source of difficulty in reading both
syntaxes is the difficulty associated with reading the existing
syntax. In other words, your argument supports a rapid transition to
the new syntax, but does not at all support the current syntax.
On Tue, Oct 15, 2019 at 11:30 PM Andrew Tomazos <andrewtomazos_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.
>
> 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
syntaxes is the difficulty associated with reading the existing
syntax. In other words, your argument supports a rapid transition to
the new syntax, but does not at all support the current syntax.
On Tue, Oct 15, 2019 at 11:30 PM Andrew Tomazos <andrewtomazos_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.
>
> 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
Received on 2019-10-18 17:06:03