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

ilya-stromberg ilya-stromberg-2009 at yandex.ru
Sat Dec 21 00:07:26 PST 2013


On Friday, 20 December 2013 at 22:40:16 UTC, Timon Gehr wrote:
>> http://wiki.dlang.org/DIP49
>> Improved points from version 1:
>> - Swap meanings of 'this(this) inout' and 'this(this) const'
>> - Inout postblit now covers all cheap (== not rebind 
>> indirections)
>> copies between same qualifiers
>>
>> Kenji Hara
>
> What about just mentioning the qualifiers of source and target 
> of the copy explicitly?
>
> this(this){ ... } // mutable source, mutable target
> this(immutable this){ ... } // immutable source mutable target
> this(const this)immutable{ ... } // const source, immutable 
> target
> this(const this)const{ ... } // const source, const target
> // ...
> this(inout this)inout{ ... } // source and target have the same 
> qualifier
> // ...
> this(this)inout{ ... } // mutable source, arbitrary target
> // ...
> this(const this)inout{ ... } // const source, arbitrary target
>
> Whenever source and target are (potentially) incompatible, the 
> postblit ensures that all fields with incompatible types in 
> source and target are reinitialized.
>
> Only unique expressions convert to 'inout' anyway, hence the 
> last signature above would correspond to unique postblit in the 
> current proposal.
>
> This would be more explicit, strictly more expressive and 
> require less special casing in the compiler implementation.

I agree, it will be the most powerful solution. And we should use 
the same rules for constructor behavior.

Also, we have strange rules in DIP 53:

> If mutable constructor is defined, if immutable constructor is 
> not defined, it will be used for const object construction.

> If immutable constructor is defined, if mutable constructor is 
> not defined, it will be used for const object construction.

What happens if we have both mutable and immutable constructors?


More information about the Digitalmars-d mailing list