> Also, the implementation that calls operator+ is extremely unlikely to ever be preferable to the one that uses prefix operator++.
This isn't the strongest argument, but operator+ is preferable if
operator++(void) cannot be any better, e.g. if you have a random
access operator and operator++(void) delegates to operator+ anyway.
In that case, you save yourself one unnecessary instantiation of
Do you really mean instantiation? I find it hard to imagine a templated iterator type where pre-increment isn't used anyway, for pretty much any use of the iterator.
operator++(void) by making operator++(int) go directly to operator+.
This is similar to saving one useless instantiation of operator> by
delegating all comparison operators to operator< directly.
Personally, I think there should be more flexibility than just "=
default" or having the compiler generate it implicitly for you.
You could make that argument for operator== and operator<=> too (and I'd disagree there too).
Perhaps a syntax such as:
> operator++(int) = operator++;
This is barely longer than "= default" and lets you manually pick what
delegation you want. This would be particularly useful for e.g. Matrix
multiplication, where operator* delegates to operator*=, despite the
opposite delegation being the norm.
This is novel syntax and adds to the difficulty of learning the language by having yet another odd corner.
Is it really so hard to just write the operator yourself for the incredibly unlikely case that you want some unusual definition? Why should "sensible defaults to remove boilerplate" cater for weird cases that almost nobody uses?