On Wed, Oct 3, 2018 at 2:50 AM Corel via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: > > On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d > > <digitalmars-d@puremagic.com> wrote: > >> > >> On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > >> > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis > >> > wrote: > >> >> 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 > >> > > >> > Eh, I don't think that moves it, but rather just constructs > >> > it in-place for the next call. > >> > >> The technical term for that is "copy elision". > > > > Okay, so copy elision is working... but moves otherwise are > > not? That's still not what we've been peddling all these years. > > A whole lot of design surface area is dedicated to implicit > > move semantics... and they don't work? What does it do? > > postblit unnecessarily? > > The impression is that you are complaining about the continuous > lack of "things" based on an incomplete knowledge of how D works > in detail ... tragically you invoke low-level features, and you > do not know the question. > > The fact that in D the structures to date are not moved, is known > for years ... take advantage of this fact, and move on. > > Work on an implementation that works, AFTER profile it, and > possibly complain about performance.
O_o .. this is one of the stranger replies I've ever gotten here.
