Deprecating this(this)

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Mar 31 23:38:06 UTC 2018


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


More information about the Digitalmars-d mailing list