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