I did see that paper, but it took a different approach from my proposed one. P1046 suggested automatically generating both operator++
overloads in terms of an addition operator as equivalent to foo += 1.
A& operator++() = default;
should generate a body like `{ *this += 1; return *this; }`, but we don't expect ordinary programmers will often =default the prefix operator (and as you point out, it flatly would be ill-formed to =default it in many cases). At the same time,
A operator++(int) = default;
should generate a body like `{ auto copy = *this; ++*this; return copy; }` — the exact implementation includes a case for non-copyable A, and is given in the paper. Ctrl+F `[&]`.
To Jan's point about matrices: P1046 also rightly points out that instead of generating `*` from `*=`, it's better to generate `*=` from (a properly move-semantified) `*`. Details in the paper.
I'd say it mirrors that changes to the equality operators in C++20. In current C++, should you decide to define operator== for your class (or of course operator<=>) then you automatically get an implicitly-generated operator!= which returns the negation of
the result of operator== for those types.
That's not quite right, and points the way to an alternative design (which I believe is the design being pursued for "autogenerated operator->" in P1046R3-or-whatever-it-becomes). C++20 never implicitly generates a defaulted `operator!=` for any class type. Instead, C++20 includes expression rewrite rules such that the expression
(a != b)
is allowed to work like any of the following:
operator!=(a, b)
a.operator!=(b)
!(operator==(a, b)) // New in C++20!
!(a.operator==(b)) // New in C++20!
!(operator==(b, a)) // New in C++20!
!(b.operator==(a)) // New in C++20!
in roughly decreasing order of preference.
We could similarly propose for C++Future that the expression
a++
should work like any of the following:
a.operator++(1)
[&]{ auto copy = a; a.operator++(); return copy; }() // New in C++Future!
[&]{ a.operator++(); }() // New in C++Future!
This wouldn't involve autogenerating any defaulted operators; it would just make `a++` a valid expression in more cases.
Expression-rewriting seems to be cheaper than generating-and-calling defaulted functions; it might be the Way of the Future. Or I might just be reading too much into a single data point (spaceship). :)
But anyway, your proposal is really exactly (a subset of) P1046R2, so you should definitely find out more about where P1046 is going next, and why the bits that failed failed, rather than start work on a completely parallel proposal.
HTH,
Arthur