What ever happened to move semantics?

[Jonathan M Davis]

On Thursday, February 29, 2024 3:10:30 AM MST Atila Neves via Digitalmars-d 
wrote:
> On Thursday, 29 February 2024 at 04:17:38 UTC, Walter Bright
>
> wrote:
> > On 2/28/2024 1:03 PM, Timon Gehr wrote:
> >> No, the idea is that the compiler enforces that it is indeed
> >> the last use and produces a compile-time error message if it
> >> cannot prove that it is the case.
> >
> > DFA works with mathematical reliability (absent compiler bugs).
> > The optimizer relies heavily on DFA; if DFA was unreliable the
> > whole edifice will fall apart. Leave move vs copy to the
> > compiler. The move vs copy/destroy choice is an optimization,
> > and should be semantically thought of it that way.
>
> Not always. Some types have to be move-only.

Yeah. One of the proposed ways to handle basic input ranges with Phobos v3
is to make them be move-only / non-copyable (and really, it's either that or
force them all to be reference types, both of which come with their own
issues). And if we do decide to make basic input ranges non-copyable, then
explicit moves are very much going to be a thing with them, and the more
type-safe we can make that the better. Being able to have the compiler do
automatic moves on last use would also be huge for that, since it would
drastically reduce the number of explicit moves which would be required, but
there would still be times when it would have to be explicit.

Also, I'm pretty sure that the folks who have been the most motivated with
regards to move constructors and move semantics (e.g. the folks at Weka)
have wanted it explicitly because of issues surrounding non-copyable types.
So, while having moves as an optimization is important (and can be big for
both performance in general and for usability with non-copyable types), I
don't think that that's actually the primary motivator behind the DIP in
question - at least not with regards to the folks who were pushing for it to
be created in the first place.

- Jonathan M Davis