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