DIP53 and DIP49 (ver2) - New definitions for qualified constructors and postblits

[ilya-stromberg]

On Thursday, 19 December 2013 at 01:38:07 UTC, Kenji Hara wrote:
> No, that's not merely syntactic choice. The 'const' 
> constructor/postblit is
> a natural conclusion derived from the semantic meaning.
>
> I tweaked descriptions in DIP to express it more clearly.

I disagree. It's the `unique` postblit/constructor becaouse it 
creates object that can be implicitly converted to the all of 
`mutable`, `immutable` and `const` types.

What should we do if we decide that we need REAL `const` 
postblit/constructor? I mean postblit/constructor that creates 
only `const` object that can't be implicitly converted to the 
`mutable` or `immutable`.

About possible rationale: see Timon Gehr's example above. 
Additional example: I want to log all my type casts (for example, 
for debug purposes). So, I can implement `const` 
postblit/constructor and use it for every cast from `mutable` and 
`immutable` to `const`.

So, please don't assume that nobody needs REAL `const` 
postblit/constructor. We can use `unique` keyword for your idea 
and, theoretically, we can create `unique` storage class for 
variables that can be implicitly converted to the all of 
`mutable`, `immutable` and `const` types.

BTW, it looks like it's quite easy to implement `unique` storage 
class only for local scope (only for function body). For example:

immutable(int)[] foo()
{
    //it's unique variable because I created it
    unique arr = new unique int[2];

    //I can change unique variable because only I have reference 
for it
    arr[0] = 10;
    arr[1] = 20;

    //unique variable can be implicitly converted to the immutable 
variable
    return arr;
}

So, `unique` storage class allows to avoid unsafe 
`cast(immutable)` cast. It's often use case, see also 
`std.exception.assumeUnique`. So, I think it will be great to 
have reserved `unique` keyword for `unique` storage class.