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?

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.

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

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.