Date: Wed, 24 Jan 2024 14:44:29 +0000
In the overwhelming majority of cases a class which is considered incrementable should provide both prefix and postfix operators in order to do as the ints do; and in that case there is a universal semantic definition and even implementation for the postfix operator which is written in terms of the prefix one.
As such, I posit that it would be beneficial if there were a mechanism to automatically obtain one set of operators from the other, in a similar vein to the changes to the equality operators in C++20. For these operators, the change would be much simpler than the equality operator due to the lack of a need to allow reversed parameter lists; as well as simpler than some operators which have previously been proposed to be automatically obtained because of just how singular the meaning of operator++ is.
The motivation here is threefold. For one, it reduces a lot of boilerplate as per the status quo the programmer effectively needs to write two different operator overloads for the same conceptual operation. Additionally, the convention of an unused int parameter to distinguish postfix from prefix is a bit of a rough edge, and exploring ways to smooth out rough edges and special case rules is in my opinion always worth doing. Thirdly, automatically generated operators help to enforce proper semantics, minimising the chances of a user (accidentally or otherwise) creating postfix operators which behave in unexpected ways. This change allows programmers to not worry about that and simply get on with what overloading operator++ should be - defining what incrementing their class means.
Syntactically, I would suggest that if there exists a user-defined operator++() or operator--() for a class, and there is no user-defined corresponding postfix overload, that the compiler can generate those postfix overloads, following the conventional pattern of calling the prefix overload and returning a copy of the object with its original value. If the user does declare a postfix operator then the compiler will not generate one, and if the class is not copyable (and there is no user-provided operator) then the postfix operator is defined as deleted.
I'd be interested to hear opinions, particularly if anyone has good counter examples for when a user would specifically want prefix operators but not postfix ones for a good semantic reason.
As such, I posit that it would be beneficial if there were a mechanism to automatically obtain one set of operators from the other, in a similar vein to the changes to the equality operators in C++20. For these operators, the change would be much simpler than the equality operator due to the lack of a need to allow reversed parameter lists; as well as simpler than some operators which have previously been proposed to be automatically obtained because of just how singular the meaning of operator++ is.
The motivation here is threefold. For one, it reduces a lot of boilerplate as per the status quo the programmer effectively needs to write two different operator overloads for the same conceptual operation. Additionally, the convention of an unused int parameter to distinguish postfix from prefix is a bit of a rough edge, and exploring ways to smooth out rough edges and special case rules is in my opinion always worth doing. Thirdly, automatically generated operators help to enforce proper semantics, minimising the chances of a user (accidentally or otherwise) creating postfix operators which behave in unexpected ways. This change allows programmers to not worry about that and simply get on with what overloading operator++ should be - defining what incrementing their class means.
Syntactically, I would suggest that if there exists a user-defined operator++() or operator--() for a class, and there is no user-defined corresponding postfix overload, that the compiler can generate those postfix overloads, following the conventional pattern of calling the prefix overload and returning a copy of the object with its original value. If the user does declare a postfix operator then the compiler will not generate one, and if the class is not copyable (and there is no user-provided operator) then the postfix operator is defined as deleted.
I'd be interested to hear opinions, particularly if anyone has good counter examples for when a user would specifically want prefix operators but not postfix ones for a good semantic reason.
Received on 2024-01-24 14:44:32