DIP 1014

[Jonathan M Davis]

On Tuesday, October 2, 2018 11:54:57 AM MDT Manu via Digitalmars-d wrote:
> On Tue, Oct 2, 2018 at 2:40 AM Walter Bright via Digitalmars-d
>
> <digitalmars-d at puremagic.com> wrote:
> > On 10/2/2018 2:17 AM, Walter Bright wrote:
> > > 1. Don't allow moving of C++ structs
> > > 2. Add a struct attribute that means "not moveable"
> > > 3. DIP 1014, which is add a __move_post_blit() function (most complex
> > > solution) 4. Use copy/destruct for C++ structs that have copy
> > > constructors (this is the old C++ solution, and is less efficient
> > > than the move constructor)>
> > The postblit solution can also work today,
> >
> > https://issues.dlang.org/show_bug.cgi?id=17448#c37
> >
> > as the DMD compiler doesn't actually move structs.
>
> Sorry... what?! DMD doesn't move? O_O
> We've been talking endlessly about move semantics for like, 10 years...
> Do the other compilers move?
>
> I don't understand... I've missed something.

Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved
structs in a number of situations - e.g. when the return value was an
rvalue. Something like

A foo();
void bar(A);

bar(foo());

is supposed to be guaranteed to move and not copy the return value. Maybe it
manages to place the return value in a way that doesn't require actually
moving it or copying it, but structs being moved was supposed to be a key
thing that D could do. Are we currently getting a bunch of copies that we
shouldn't be getting because the compiler isn't yet doing moves when it
should be? A number of us have been answering questions for years based on
what the spec and TDPL say indicating that the compiler moves structs.

And while I'm all for having objects be moveable by default, I confess that
I don't understand what the problem is with the opPostMove idea that the DIP
is presenting. I don't think that it should be the norm by any means, but it
sure seems like it's cleanly solving a major problem with interacting with
C++, and it makes it possible to do stuff like have pointers and dynamic
arrays refer to a structs internals in a way that we can't @safely do right
now (even though occasionally, it really would be useful to be able to do
it). And it sure seems like opPostMove fits in cleanly with the current
design, though maybe I'm missing something. Either way, without something
like it, we're clearly missing some key functionality for a systems language
- particularly one that wants to interoperate with C++.

- Jonathan M Davis