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