DIP 1014

Stanislav Blinov stanislav.blinov at gmail.com
Thu Oct 4 10:43:10 UTC 2018


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


More information about the Digitalmars-d mailing list