DIP 1014

[Manu]

On Tue, Jul 2, 2019 at 5:51 PM RazvanN via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Tuesday, 2 July 2019 at 05:32:07 UTC, Tremor wrote:
> > On Sunday, 30 September 2018 at 04:34:20 UTC, Manu wrote:
> >> Who knows about DIP 1014? (struct move hook)
> >> Is it well received? Is it likely to be accepted soon?
> >>
> >> I'm working on the std::string binding, it's almost
> >> finished... but
> >> then I hit a brick wall.
> >> GNU's std::string implementation stores an interior pointer!
> >> >_<
> >>
> >> No other implementation does this. It's a really bad
> >> implementation actually, quite inefficient. It could make
> >> better use of its space for small-strings if it wasn't wasting
> >> 8-bytes for an interior pointer to a small string buffer...
> >>
> >> Anyway, I'm blocked until this DIP is accepted; so, is it
> >> looking promising?
> >
> > Is any update for this ?
> >
> > DIP1014 is fatal for implement safe ref count,  I don't trust a
> > language call them self system language without safe ref count.
> >
> > This is also a major block for implement GNU CPP std::string,
> > cpp ABI compatible is  another import goal for D.
> >
> > I just with I has the skill to work on this,  If nobody has no
> > time to work on this. maybe some one can give a guide about how
> > to implement this ?
> >
> > like the step to do:
> >
> > step 1:  example to add some build in id for opPostMove
> >
> > step 2: which part code to modify to hook opPostMove with
> > rvalue or lvalue move
> >
> > step 3: how to glue it with DMD and LDC backend to generate asm
> > code.
> >
> > Maybe there should be a new thread to talk about this.
> >
> > The github user thewilsonator is like a hero to me, maybe when
> > he get free time can take a look for this.
>
> After implementing the copy constructor as a substitute for the
> postblit, we realized that the fundamental flaw that the postblit
> had (automatic copying) would also manifest in the case of
> opPostMove; in Shachars' there is no mention what happens when
> the source and destination are differently qualified. I suspect
> that before implementing the DIP we need to sort this out and it
> might be preferable to imlement a move constructor a la C++
> rather then rely on automatic moving.

Wouldn't it just call the opPostMove qualified identical to the type
that was moved?
Is it that you can't do qualifier conversions across a move, but you
might like to? This kinda feels like a slightly separate issue.