On Wednesday, 18 December 2013 at 21:11:10 UTC, Joseph Rushton
Wakeling wrote:
On 18/12/13 21:11, ilya-stromberg wrote:
Sorry if I miss something, but I don't understand this analogy.
`const` means that original type can be `mutable` or
`immutable`, so both
`mutable` and `immutable` types can be implicitly converted to
the `const` type.
If I understand DIP correctly, unique postblit/constructor
returns `unique` type
that can be implicitly converted to the all of `mutable`,
`immutable` and
`const` types. So, this behavior is the opposite of current
`const` behavior.
So, where is analogy here?
Well, as far as I understand it (happy to be corrected if
wrong), the point of this DIP is to offer a way to _easily_
create immutable and const instances of objects (which as I
recall from the last time I tried to do it, is a real PITA).
So, you have your regular mutable constructor -- 'this' with no
qualifications -- which can be used to construct mutable
instances.
You have this(...) immutable, which can be used to construct
immutable instances.
And you have this(...) const (aka "unique"), which can be used
to construct both immutable and mutable instances.
It seems to me that this is a very natural relation to the
existing interpretation of mutable, immutable and const
variables by the language, and e.g. the way that immutable,
mutable and const function parameters are addressed.
I understood your position, but it's bad analogy because we can
have both `const` and `unique` postblits/constructors (at least
in theory).
I want to say that compiler can implicitly convert `mutable` and
`immutable` types to the `const` type, but we can add `const`
postblit/constructor for better control this cast (of course,
only if we decide that it's really need).
In other hand, `unique` postblit/constructor creates `unique`
type that can be implicitly convert to the `mutable` and
`immutable` types. It's different things.
So, theoretically we can have both `const` and `unique`
postblits/constructors. We shouldn't mix 2 different semantics.
I think the main problem with this DIP is `unique`
postblit/constructor because we don't know what exactly means
`unique`. Maybe we should write another DIP with this description
or don't implement `unique` postblit/constructor (for now, I
hope).
