Review of DIP49

[Timon Gehr]

On 02/03/2014 12:54 AM, Andrei Alexandrescu wrote:
> * Const postblit is spelled "this(this) const" but that's misleading
> because it's really "this(whatever1 this) whatever2"  with whatever1 and
> whatever2 being arbitrary qualifiers.  We should probably find a more
>> descriptive syntax for that. "this(this) auto" comes to mind. We can
>> even add a contextual keyword such that the compiler recognizes
>> "this(this) unique" without otherwise giving "unique" any special meaning.

I think it is a weakness of the 'inout' qualifier (or more generally, 
the polymorphic part of the type system) that this cannot be expressed 
in an orthogonal way. (It only allows one type constructor variable per 
scope.)

Effectively, one would want something like:

this(inout this) inout' { ... }

i.e. two unrelated wildcards.
(Not an actual syntax proposal.)

>
> * So we're left with the following postblitting rules as the maximum:
>
> struct T {
>    this(this); // all upcasts including identity
>    this(const this); // construct T from const(T)
>    this(const this) immutable; // construct immutable(T) from const(T)
>    this(immutable this); // construct T from immutable(T)
>    this(this) immutable; // construct immutable(T) from T
> }
>
> Some could be missing, some could be deduced, but this is the total set.
> ...

We'd also want to consider inout.

> * Consider a conversion like "this(this) immutable" which constructs an
> immutable(T) from a T. This is tricky to typecheck because fields of T
> have a mutable type when first read and immutable type after having been
> written to.

The language needs to track initialized fields in constructors anyways, 
so I think that effort can be shared to some extent.

> That raises the question whether the entire notion of
> postblitting is too complicated for its own good. Should we leave it as
> is and go with classic C++-style copy construction in which source and
> destination are distinct objects? I think that would simplify both the
> language definition and its implementation.

If the source object can be obtained by ref, it also increases modelling 
power slightly. (e.g. initialize it on copy in order to have actual 
reference semantics for structs with default initialization.)

This also has the benefit that one does not have to pay for postblits 
and destructors of fields one is going to reinitialize anyway.

The main drawback of copy-construction with regard to postblit is that 
(potentially less efficient?) boilerplate is required to copy all fields 
over manually, which I think was what motivated the concept.

Of course, copy construction does not address the need to copy from any 
qualifier to any qualifier, which would IMO rather be achieved by 
improvements to other parts of the type system anyway. (A weakness of 
DIP49 is that it is impossible to abstract out identical code snippets 
that use unique postblit at different type qualifiers.)