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
