On Wed, 24 Jan 2024 at 18:43, Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > 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?