DIP 1014

[Manu]

On Wed, Oct 3, 2018 at 2:50 AM Corel via Digitalmars-d
<digitalmars-d at 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 at 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.