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

On 02/03/2014 01:58 AM, Andrei Alexandrescu wrote:
>
> Overall, I'm not clear what DIP53 does.

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.

On 02/03/2014 02:18 AM, Timon Gehr wrote:
> It removes the concept of const constructors and inout constructors from
> the language.  ...

Apparently my memory was failing me. inout constructors actually stay as they are, but the examples I gave are still valid.

On Monday, 3 February 2014 at 00:58:55 UTC, Andrei Alexandrescu wrote:
> Overall, I'm not clear what DIP53 does.

It tries to reinvent isolated, poorly.

2014-02-03 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> 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