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