Deprecating this(this)

[Johannes Loher]

Am 01.04.2018 um 01:38 schrieb Andrei Alexandrescu:
> 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.
> 
> 
> Thanks,
> 
> Andrei

This seems really sudden, april fool's joke? Not really sure, as there
are real problems with this(this)...