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