Review of DIP49

[Andrei Alexandrescu]

Here are a few questions and comments:

* Why is there an immutable postblit? I wonder if there are cases in 
which that's needed. Most of the time it's fine to just memcpy() the 
data - it's immutable anyway so nothing will change! In fact there is 
one use case for immutable postblit, and that's refcounting (when 
copying data the reference count must be incremented). But that would be 
increment via a pointer, which is not allowed in your proposal. (I think 
it is ok for the postblit proposal to not cover refcounting - we can 
make it built in the language.)

* The inout case looks good, but again we need to have some good 
examples on when it would be necessary.

* What happens if an object defines both the mutable and the inout 
version of postblit? I assume the mutable has priority when duplicating 
mutable object. The DIP should clarify that.

* 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.

* My main beef is with this constructor. I'll refer to it henceforth as 
"the unique constructor".

* Qualifiers obey a hierarchy, i.e. const(T) is a supertype of both T 
and immutable(T) as shown below with ASCII art.

  const(T)
   /\
  /  \
T   immutable(T)

That imparts structure over the mixed-qualifier constructors. However, 
that structure is missing from the unique constructor; all 
mixed-qualifier constructors are heaped into one. This makes the rules 
forced for certain constructors (e.g. constructing a const(T) from a T 
should be much less restricted than constructing a T from a const(T)). 
The proposed unique constructor is not sensitive to such distinctions.

* The "unique expression" definition is quite strong and we should 
refine it and reuse in other contexts as well.

* The section "Overloading of qualified postblits" is great because it 
brings back the subtyping structure! It says: "If mutable postblit is 
defined, it is alwasy used for the copies: (a) mutable to mutable; (b) 
mutable to const". Indeed that is correct because mutable to const is a 
copy to a supertype. To respect subtyping, we should also add (c) 
immutable to const; (d) const to const; (e) immutable to immutable. That 
way we have a simple rule: "this(this) is invoked for all upcasts 
obtained by qualifiers". Wonderful!

* If we go forward with the idea above, we only need to treat the 
remaining cases of downcasts and cross-casts across the subtyping 
hierarchy:

(a) downcasts: const(T) -> T and const(T) -> immutable(T)
(b) cross-casts: immutable(T) -> T and T -> immutable(T)

* The use of subtyping above would replace the elaborate rules in 
section "Overloading of qualified postblits". In fact they seem to agree 
95% of the time. By the way there are some confusing negations e.g. "if 
mutable postblit is not defined, it will be used for the copies". I 
assume the "not" should be removed?

* 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.

* 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. 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.

* The section "Why 'const' postblit will called to copy arbitrary 
qualified object?" alludes to the subtyping relationship among 
qualifiers without stating it.



Andrei