http://wiki.dlang.org/DIP53
There are quite a few similarities with DIP49 so I won't discuss the
shared parts. In fact my only comment is that I'm unclear on the
motivation and the progress marked by this DIP (i.e. assuming it's
implemented to perfection, it would make D better because...). One
argument is that "current definition is very complex and hard to
understand" but DIP53 doesn't seem to make matters any simpler.
What adds to the confusion is that some rules already work today so it's
unclear what's already there and where the changes are.
Overall, I'm not clear what DIP53 does. It may only be a matter of the
writeup itself. Also I'll note that there might be subtleties of current
constructors I'm inadvertently glossing over.
Andrei

It removes the concept of const constructors and inout constructors from
the language. The old const constructor syntax is then used to introduce
a new feature that is very similar to inout constructors (the unique
constructor) but requires special type checking rules for
const-qualified data. It mostly removes features. Eg, the following code
will break:
auto foo(const(int)[] x){
struct S{
int[] x;
this(int y)const{ this.x=x; }
}
// ...
}
Some new code that wouldn't have been possible to write in an analogous
way before:
struct S{
int x;
int[] y;
this(int delegate(inout(int)[]) dg, inout(int)[] x)const{
this.x=dg(x);
this.y=[this.x];
}
}
void main(){
immutable s = S(x=>x[0],[1]);
auto s = S((immutable x)=>x[0],cast(immutable)[2]);
}
Whatever strange class of new use cases DIP53 actually enables is fully
covered by multiple inout-qualifiers as discussed in my previous post.

http://wiki.dlang.org/DIP53
There are quite a few similarities with DIP49 so I won't discuss the
shared parts. In fact my only comment is that I'm unclear on the motivation
and the progress marked by this DIP (i.e. assuming it's implemented to
perfection, it would make D better because...). One argument is that
"current definition is very complex and hard to understand" but DIP53
doesn't seem to make matters any simpler.
What adds to the confusion is that some rules already work today so it's
unclear what's already there and where the changes are.
Overall, I'm not clear what DIP53 does. It may only be a matter of the
writeup itself. Also I'll note that there might be subtleties of current
constructors I'm inadvertently glossing over.

Please read "Motivation" section.
Currently implemented and documented "unique constructor" feature is too
hard to understand. and it is not consistent with DIP49. So if DIP49 is
accepted, I strongly recommend to accept also DIP53.
Kenji Hara