On 04/10/18 11:16, Paolo Invernizzi wrote:
> While I want to thank you both, about the quality of this thread, what kind of "consequences that go beyond what I think you understand" are you thinking of? Can you give an example?

Assuming I understand Stanislav's proposal correctly (an assumption I'm reluctant to make, hence my request for something more formal), it boils down to two points:

* move the data as part of the call hook rather than before
* Use a different name and signature on the hook function

The first one we can argue for or against. My original proposal was phrased the way it was precisely because that's the way copying works in D (copy first, patch the data later). About a week after I submitted it, Andrei came forward with requesting to move to copy constructors.

The second, to me, is a non-starter. The only way you'd get a function who's signature is:
void someName(Type rhs);

But which actually maintains rhs's address from before the call is if the compiler treats "someName" as a special case, and emits code which would normally be emitted for the function:

void someName(ref Type rhs);

That's why it was important for me to clear up whether there is *ever* a case in the current language where that happens (answer: only by accident, which is the same as saying "no").

So to get that to work, you'd need to insert a special case into the ABI of the language: if the function's name is someName, treat it differently.

At this point, you might as well call a spade a spade, and just give the function that signature explicitly. s/someName/opPostMove/, and you get DIP 1014 (as far as point #2 is concerned).

Shachar

On Thursday, 4 October 2018 at 08:32:44 UTC, Shachar Shemesh wrote:
> On 04/10/18 11:16, Paolo Invernizzi wrote:
>> While I want to thank you both, about the quality of this thread, what kind of "consequences that go beyond what I think you understand" are you thinking of? Can you give an example?
>
> Assuming I understand Stanislav's proposal correctly (an

Yes it seems you do.

> assumption I'm reluctant to make, hence my request for something more formal), it boils down to two points:
>
> * move the data as part of the call hook rather than before
> * Use a different name and signature on the hook function

Yes, exactly.

> The first one we can argue for or against. My original proposal was phrased the way it was precisely because that's the way copying works in D (copy first, patch the data later). About a week after I submitted it, Andrei came forward with requesting to move to copy constructors.

> The second, to me, is a non-starter. The only way you'd get a function who's signature is:
> void someName(Type rhs);
> But which actually maintains rhs's address from before the call is if the compiler treats "someName" as a special case, and emits code which would normally be emitted for the function:
> void someName(ref Type rhs);

It would have to be special if you don't want to leave room for the compiler implementors. The calling convention for particular types (i.e. those that do have a move hook defined) would have to be enforced in some way. See the neighbor thread wrt move semantics by kinke.

> That's why it was important for me to clear up whether there is *ever* a case in the current language where that happens (answer: only by accident, which is the same as saying "no").

Which is, however, not a reason to formalize it and make it a requirement for an isolated specific case, such as this one, utilizing a syntax that is currently not used by the language. As opposed to trying to fit existing language semantics to something that the language didn't seem to want to allow in the first place.

> So to get that to work, you'd need to insert a special case into the ABI of the language: if the function's name is someName, treat it differently.

Yes, that's what I'm talking about.

> At this point, you might as well call a spade a spade, and just give the function that signature explicitly. s/someName/opPostMove/, and you get DIP 1014 (as far as point #2 is concerned).

On 04/10/18 13:43, Stanislav Blinov wrote:
>> * move the data as part of the call hook rather than before
>> * Use a different name and signature on the hook function
> 
> Yes, exactly.
> 

> 
> It would have to be special if you don't want to leave room for the compiler implementors.

That's not how standards work. If you don't want compiler implementors to have a choice in the matter, you put MUST in the specs. Doing anything else is, by and large, considered harmful.

> The calling convention for particular types (i.e. those that do have a move hook defined) would have to be enforced in some way. See the neighbor thread wrt move semantics by kinke.

Two distinct things. Kinke was talking about how to pass a struct through the ABI. You are talking about special-casing a specific name.

Not to mention, your special case is to transform it to something you can *already* specify in the language. Why?

> Which is, however, not a reason to formalize it and make it a requirement for an isolated specific case, such as this one, utilizing a syntax that is currently not used by the language.

There is positively nothing in DIP 1014 that is "syntax not used by the language". Quite the contrary.

> As opposed to trying to fit existing language semantics to something that the language didn't seem to want to allow in the first place.

Formalize it as a suggestion, and we can discuss the "as opposed to". Like I said, I think there's a lot you're glossing over here (such as backwards compatibility).

Shachar

On Thursday, 4 October 2018 at 12:08:38 UTC, Shachar Shemesh wrote:

> Two distinct things. Kinke was talking about how to pass a struct through the ABI. You are talking about special-casing a specific name.

Not just name, but argument passing as well.

> Not to mention, your special case is to transform it to something you can *already* specify in the language. Why?

Because that syntax pertains specifically to construction, which is what a compiler move is; is not currently used by the language (the fact that the compiler doesn't error on it is an oversight); enforces calling convention.

>> Which is, however, not a reason to formalize it and make it a requirement for an isolated specific case, such as this one, utilizing a syntax that is currently not used by the language.
>
> There is positively nothing in DIP 1014 that is "syntax not used by the language". Quite the contrary.

Which is what I said in the very next sentence, so I'm not sure what your point is here. It's like we're having a discussion but we aren't at the same time.

>> As opposed to trying to fit existing language semantics to something that the language didn't seem to want to allow in the first place.

> Formalize it as a suggestion, and we can discuss the "as opposed to".

Alright, let's get back to it after the weekend then.

> Like I said, I think there's a lot you're glossing over here (such as backwards compatibility).

Backwards compatibility? With what, exactly? Non-existing explicit moves?

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.

On Tuesday, 2 July 2019 at 05:32:07 UTC, Tremor wrote:
> Is any update for this ?

Les De Ridder has implemented the druntime function and made phobos use it for its move function, all thats left is to make the compiler insert a call to it when it moves structs around.

> 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

That would go here:

https://github.com/dlang/dmd/blob/master/src/dmd/id.d#L63

you'd need one for https://github.com/dlang/druntime/blob/master/src/object.d#L151 as well

> step 2: which part code to modify to hook opPostMove with rvalue or lvalue move

Would probably want to insert the call in, Razvan Nitu would probably know better/in more detail.

https://github.com/dlang/dmd/blob/b359735d1034c77aa5b59dff9a8b815fb3eb14c9/src/dmd/expression.d#L468

> step 3: how to glue it with DMD and LDC backend to generate asm code.

This should be no problem, all that is needed is to insert a call to, https://github.com/dlang/druntime/blob/master/src/object.d#L151 Its all front end stuff, i.e. LDC will be able to use whatever the front end does with no problem.

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

I'm humbled, but a bit busy. Don't let me stop you opening a PR though. I'm sure Razvan and I can try to help you there.

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.

On Tuesday, 2 July 2019 at 07:19:10 UTC, Nicholas Wilson wrote:
> That would go here:
>
> https://github.com/dlang/dmd/blob/master/src/dmd/id.d#L63
>

Thanks for the tips, I manage to made a patch: https://paste.ofcode.org/xGnhS2KcXvtmENwyRPQXua

The rest hard work is made the code to be call from https://github.com/dlang/dmd/blob/b359735d1034c77aa5b59dff9a8b815fb3eb14c9/src/dmd/expression.d#L468 or  src/dmd/dinterpret.d (I need help here).


On Tuesday, 2 July 2019 at 07:48:06 UTC, RazvanN 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.


Correct me if I am wrong.  I think the opPostMove should always use for the same qualified type.  for example if a function return a shared(struct), then the opPostMove  also accept shared(struct) from a shared(struct) instance.


Please feel free to use this patch https://paste.ofcode.org/xGnhS2KcXvtmENwyRPQXua to made PR and start the work.  I can made the PR but I am afraid this is all I can do for this task(I will try, but I can not understand any of dinterpret.d/expression.d).

On Tuesday, 2 July 2019 at 07:48:06 UTC, RazvanN 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.


Maybe this is work for us ?

1. opPostMove always apply to same qualified type

2. If the opPostMove apply to immutable instance, it should call copyConstructor instead. The diff from copyConstructor with opPostMove, the original instance is dropped without call dtor.

3. The  original instance should be scope instance without any escape ref.

On Tuesday, 2 July 2019 at 08:05:35 UTC, Tremor wrote:
> On Tuesday, 2 July 2019 at 07:19:10 UTC, Nicholas Wilson wrote:
>> That would go here:
>>
>> https://github.com/dlang/dmd/blob/master/src/dmd/id.d#L63
>>
>
> Thanks for the tips, I manage to made a patch: https://paste.ofcode.org/xGnhS2KcXvtmENwyRPQXua
>
> The rest hard work is made the code to be call from https://github.com/dlang/dmd/blob/b359735d1034c77aa5b59dff9a8b815fb3eb14c9/src/dmd/expression.d#L468 or  src/dmd/dinterpret.d (I need help here).
>
>
> On Tuesday, 2 July 2019 at 07:48:06 UTC, RazvanN 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.
>
>
> Correct me if I am wrong.  I think the opPostMove should always use for the same qualified type.  for example if a function return a shared(struct), then the opPostMove  also accept shared(struct) from a shared(struct) instance.
>
>
> Please feel free to use this patch https://paste.ofcode.org/xGnhS2KcXvtmENwyRPQXua to made PR and start the work.  I can made the PR but I am afraid this is all I can do for this task(I will try, but I can not understand any of dinterpret.d/expression.d).

Make the PR, so that others can review it.