DIP53 and DIP49 (ver2) - New definitions for qualified constructors and postblits
ilya-stromberg
ilya-stromberg-2009 at yandex.ru
Wed Dec 18 13:53:24 PST 2013
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).
More information about the Digitalmars-d
mailing list