On Tue, Jul 2, 2019 at 5:51 PM RazvanN via Digitalmars-d <digitalmars-d@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.

On Tuesday, 2 July 2019 at 23:05:14 UTC, Manu wrote:
> On Tue, Jul 2, 2019 at 5:51 PM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Tuesday, 2 July 2019 at 05:32:07 UTC, Tremor wrote:
>> > [...]
>>
>> 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.

It is not a separate issue. Currently, the compiler may perform
a move that co-occurs with an implicit conversion:

struct T { ... }
T fun();
const x = fun(); // a move may occur together with a qualifier change

This is valid code. With DIP1014 it becomes invalid since the signature of
__move_post_blt is :

void __move_post_blt(S)(ref S newLocation, ref S oldLocation) nothrow if( is(S==struct) );

The above case is not even mentioned in the DIP and it should.

On Wednesday, 3 July 2019 at 08:27:49 UTC, RazvanN wrote:
> On Tuesday, 2 July 2019 at 23:05:14 UTC, Manu wrote:
>> On Tue, Jul 2, 2019 at 5:51 PM RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

Also there is the problem of typechecking the move operator as a function.Let's take a look at a slightly modified version of the example that Shachar provided:

struct Tracker {
    static uint globalCounter;
    uint localCounter;
    uint* counter;

    @disable this(this);

    this(bool local) {
        localCounter = 0;
        if( local )
            counter = &localCounter;
        else
            counter = &globalCounter;
    }

    void increment() {
        (*counter)++;
    }

    //void opPostMove(const ref Tracker oldLocation) {
    void opPostMove(immutable ref Tracker oldLocation) immutable {
        if( counter is &oldLocation.localCounter )
            counter = &localCounter;
    }
}

This code will not compile even though it should. And here we open the door of the postblit problems.

On Wednesday, 3 July 2019 at 09:31:38 UTC, RazvanN wrote:
> On Wednesday, 3 July 2019 at 08:27:49 UTC, RazvanN wrote:
>>> [...]
>
> Also there is the problem of typechecking the move operator as a function.Let's take a look at a slightly modified version of the example that Shachar provided:
>
> [...]

Is there any situation where a move-related hook will do anything other than "fix" indirections in the destination of the move?

On Wednesday, 3 July 2019 at 11:18:20 UTC, aliak wrote:
> On Wednesday, 3 July 2019 at 09:31:38 UTC, RazvanN wrote:
>> On Wednesday, 3 July 2019 at 08:27:49 UTC, RazvanN wrote:
>>
>> Also there is the problem of typechecking the move operator as a function.Let's take a look at a slightly modified version of the example that Shachar provided:
>>
> Is there any situation where a move-related hook will do anything other than "fix" indirections in the destination of the move?

copy constructor or copy+postblit can be very expensive operations in some cases, and I am in doubt that compiler generate code only with copy without some move/memmoves.
auto x = fun(); // a move may occur
so at code generation levels in any case we have move/memmove operations, why not pull out it to user level where user can control it in some cases more predictably and easily?

for some interop projects (like DPP https://dlang.org/blog/2019/04/08/project-highlight-dpp/ ) it can be helpful too: std::string uses Small String Optimization technique https://stackoverflow.com/a/28003328 with video about GCC string and fbstring https://youtu.be/kPR8h4-qZdk?t=654 (CppCon 2016: Nicholas Ormrod “The strange details of std::string at Facebook") - I just pointed to fbstring internals that most probably used as Clang strings (from SO answer), but M$ and GCC uses some kind of GCC ver>=5 string internals (find it in video too)

probably it can be tied with DIP 1021 (Borrowing and Ownership) - when code doesn't contains another refs to object compiler can just move the one without expensive copy/constructor/destructor.

nobody can assure (wrong word meaning? idk English) that "move" don't needed at all.
so lets add it with user friendly details control.