DIP 1014--Hooking D's struct move semantics--Final Review

[aliak00]

On Thursday, 12 July 2018 at 10:24:40 UTC, Shachar Shemesh wrote:
> On 29/06/18 15:35, aliak wrote:
>> On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote:
>>> On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
>>>>
>>>> Thanks in advance for your participation.
>>>
>>> For those of you using the NNTP or mailing list interfaces, 
>>> this is the thread to respond in. Thanks!
>> 
>> Alo!
>> 
>> This is great!
>> 
>> Just a clarification about the last paragraph phrasing
>> 
>> The last line: "We can further reduce this problem by calling 
>> the function opPostMove." seemed to imply that an alternate 
>> name to opPostMove would be mentioned, but am I correct in 
>> understanding that it is just saying that "naming this second 
>> function as op* will keep code breakage to a minimum" ?
>
> This is a left over from a previous draft, where the operator 
> was called "opMove". It should be removed.
>
>> Also, what should happen if someone defines an opPostMove for 
>> a class. Compile error or? Should something about that be 
>> mentioned?
>
> I think nothing should happen. The function would be ignored, 
> just like it is today. I am open to hear other ideas, however.
>
> I'm not sure whether it should be explicitly mentioned or not.
>
> Shachar

A postblit on a class issues a compiler error. And an identity 
opAssign on a class also issues a compiler error. So I'm not sure 
how this would be different. And the page In 
https://dlang.org/spec/operatoroverloading.html also explicitly 
mentions differences between ops on classes or structs.

Cheers,
- Ali