Deprecating this(this)

[Jonathan M Davis]

On Saturday, March 31, 2018 19:38:06 Andrei Alexandrescu via Digitalmars-d 
wrote:
> We need to have a simple recipe on how to define a canonical object.
> That would include requirements such as:
>
> * should work with mutable, const, immutable, and shared
> * the right way to define constructor(s)
> * the right way to define copying
> * the right way to define destructor(s)
>
> I've asked my student Razvan to document the behavior of this(this). His
> work:
>
> https://github.com/dlang/dmd/pull/8055
> https://github.com/dlang/dlang.org/pull/2281
> https://github.com/dlang/dlang.org/pull/2299
>
> ... reveals a puzzling array of behaviors. Sometimes the typechecking is
> wrong, too.
>
> I think it's very important for us to have a simple, correct, and
> canonical way of defining structs in the D language that work with the
> language features: qualifiers, pure, safe, and nogc.
>
> Once we have that, we can encapsulate desirable abstractions (such as
> @nogc safe collections that work in pure code), regardless of how
> difficult their implementations might be. It seems that currently
> this(this) does not allow us to do that.
>
> Eduard, another student I work with, has made steps toward a collections
> library that rant into difficulties:
>
> * @safe is achievable with relative ease
>
> * immutable and const are very difficult, but we have an attack
> (assuming copy construction gets taken care of)
>
> * @nogc is doable with a couple of conventions for allocators
>
> * pure is difficult
>
> * making them work together is very difficult
>
> We need to offer features, tools, and guidance toward creating simple
> encapsulated types that work well with D's own abstractions. Once we
> have that we can build libraries to work satisfactorily for any domain.
>
> I think the way to move forward is to deprecate this(this) entirely and
> create a DIP that allows people to define truly encapsulated structs.
> This is important, urgent, and of huge impact.
>
> I am looking for folks to assist me in creating a DIP for that. There
> will be a _lot_ of work involved, so don't take it lightly.

Another potential issue is whether any of this does or should relate to

https://github.com/dlang/DIPs/pull/109

and it's solution for hooking into to moves. I'm not at all sure that what
happens with that needs to be related to this at all, but it might.

- Jonathan M Davis