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.
