• FeepingCreature (10/10) Jun 29 2018 I'm doing a pull request to rewrite Nullable to use
• Eugene Wissner (4/14) Jun 29 2018 You can move only exactly the same type. with opAssign you can
• FeepingCreature (6/9) Jun 29 2018 Sorry, that was unclear; I meant to ask for usecases for
• Eugene Wissner (15/24) Jun 29 2018 Not an exact answer, but there is a DIP to add kind of move

FeepingCreature <feepingcreature gmail.com> writes:

I'm doing a pull request to rewrite Nullable to use 
moveEmplace/move to replace its internal value. I'm considering 
whether it's better to let Nullable destroy its existing value, 
then memcpy the new one over it (via move()), or if it already 
has a value in it, if an opAssign to Nullable should assign to 
the underlying type.

With that in mind: what *is* opAssign actually good for, now that 
we have move/moveEmplace?

What usecase for opAssign would break if we replaced it with 
destructor + copy + postblit?

Eugene Wissner <belka caraus.de> writes:

On Friday, 29 June 2018 at 07:15:38 UTC, FeepingCreature wrote:
 I'm doing a pull request to rewrite Nullable to use 
 moveEmplace/move to replace its internal value. I'm considering 
 whether it's better to let Nullable destroy its existing value, 
 then memcpy the new one over it (via move()), or if it already 
 has a value in it, if an opAssign to Nullable should assign to 
 the underlying type.

 With that in mind: what *is* opAssign actually good for, now 
 that we have move/moveEmplace?

 What usecase for opAssign would break if we replaced it with 
 destructor + copy + postblit?

You can move only exactly the same type. with opAssign you can 
assign a differnt type. So opAssign should forward assignment to 
the underlying type if you assign nor Nullable!T nor T.

FeepingCreature <feepingcreature gmail.com> writes:

On Friday, 29 June 2018 at 07:31:42 UTC, Eugene Wissner wrote:
 You can move only exactly the same type. with opAssign you can 
 assign a differnt type. So opAssign should forward assignment 
 to the underlying type if you assign nor Nullable!T nor T.

Sorry, that was unclear; I meant to ask for usecases for 
T::opAssign(T). Maybe the reason to allow this is just that it's 
a generalization of the actually useful T::opAssign(S), but I 
want to know if there's a specific usecase for calling 
specifically T::opAssign(T).

Eugene Wissner <belka caraus.de> writes:

On Friday, 29 June 2018 at 07:37:46 UTC, FeepingCreature wrote:
 On Friday, 29 June 2018 at 07:31:42 UTC, Eugene Wissner wrote:
 You can move only exactly the same type. with opAssign you can 
 assign a differnt type. So opAssign should forward assignment 
 to the underlying type if you assign nor Nullable!T nor T.

 Sorry, that was unclear; I meant to ask for usecases for 
 T::opAssign(T). Maybe the reason to allow this is just that 
 it's a generalization of the actually useful T::opAssign(S), 
 but I want to know if there's a specific usecase for calling 
 specifically T::opAssign(T).

Not an exact answer, but there is a DIP to add kind of move 
constructor to D:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1014.md

And Andrei mentioned plans to write a DIP to add a copy 
constructor (and maybe deprecate postblit some day, o leave at as 
is).

So yes people have use cases where they have to access the source 
instance (like in T.opAssign(T)).

The first DIP mentions counting of all instances in the 
application, it can be some kind of "intelligent" assignment, 
where you copy/move only some parts of the source instance (and 
not copy/move it completely) or adjusting the internal 
references/structure of the source instance - something like 
this, I think.