http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.

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

On 12/17/13 7:42 PM, Kenji Hara wrote:
> http://wiki.dlang.org/DIP53
> Redesign currently implemented qualified constructor concept.
>
> 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

Fantastic. I started to read DIP49 earlier today and it really rings well. I'll read the updated one.

Andrei

On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
> http://wiki.dlang.org/DIP53
> Redesign currently implemented qualified constructor concept.
>
> 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

This is awesome, maybe I'll be able to use immutable in my code, thanks to this and your bugfixes (opAssign)!

One suggestion though - maybe @unique would be better than const for unique postblit/constructor, I think static confusion is an important lesson from the past.

On Wednesday, 18 December 2013 at 11:10:10 UTC, QAston wrote:
> On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
>> http://wiki.dlang.org/DIP53
>> Redesign currently implemented qualified constructor concept.
>>
>> 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
>
> This is awesome, maybe I'll be able to use immutable in my code, thanks to this and your bugfixes (opAssign)!
>
> One suggestion though - maybe @unique would be better than const for unique postblit/constructor, I think static confusion is an important lesson from the past.

I agree, `@unique` attribute looks more clear.
BTW, we can use `unique` keyword for unique postblit/constructor. Also, we can use this keyword for unique storage class of variables and related issues.

On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
> http://wiki.dlang.org/DIP53
> Redesign currently implemented qualified constructor concept.

Thank you very much -- this is going to be really useful.

I think adding new keyword/attribute just for readability is overkill.

Kenji Hara


2013/12/18 ilya-stromberg <ilya-stromberg-2009@yandex.ru>

> On Wednesday, 18 December 2013 at 11:10:10 UTC, QAston wrote:
>
>> On Wednesday, 18 December 2013 at 03:42:46 UTC, Kenji Hara wrote:
>>
>>> http://wiki.dlang.org/DIP53
>>> Redesign currently implemented qualified constructor concept.
>>>
>>> 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
>>>
>>
>> This is awesome, maybe I'll be able to use immutable in my code, thanks to this and your bugfixes (opAssign)!
>>
>> One suggestion though - maybe @unique would be better than const for unique postblit/constructor, I think static confusion is an important lesson from the past.
>>
>
> I agree, `@unique` attribute looks more clear.
> BTW, we can use `unique` keyword for unique postblit/constructor. Also, we
> can use this keyword for unique storage class of variables and related
> issues.
>

Kenji Hara:

> I think adding new keyword/attribute just for readability is overkill.

Making the code more explicit and easy to understand, using the right words, is rather important. So I like @unique, that can probably be re-uses for another purpose.

What's worse than having many keywords is having them with multiple meanings. Otherwise are you willing to explain again and again to future people in D.learn that specific "const" doesn't really mean const, it really means... and so on :-)

Bye,
bearophile

On Wednesday, 18 December 2013 at 15:29:44 UTC, bearophile wrote:
> Kenji Hara:
>
>> I think adding new keyword/attribute just for readability is overkill.
>
> Making the code more explicit and easy to understand, using the right words, is rather important. So I like @unique, that can probably be re-uses for another purpose.
>
> What's worse than having many keywords is having them with multiple meanings. Otherwise are you willing to explain again and again to future people in D.learn that specific "const" doesn't really mean const, it really means... and so on :-)
>
> Bye,
> bearophile

Which additional meaning will const qualifier have?

On 12/18/2013 04:47 PM, Maxim Fomin wrote:
> On Wednesday, 18 December 2013 at 15:29:44 UTC, bearophile wrote:
>> Kenji Hara:
>>
>>> I think adding new keyword/attribute just for readability is overkill.
>>
>> Making the code more explicit and easy to understand, using the right
>> words, is rather important. So I like @unique, that can probably be
>> re-uses for another purpose.
>>
>> What's worse than having many keywords is having them with multiple
>> meanings. Otherwise are you willing to explain again and again to
>> future people in D.learn that specific "const" doesn't really mean
>> const, it really means... and so on :-)
>>
>> Bye,
>> bearophile
>
> Which additional meaning will const qualifier have?

It will be used to annotate a postblit that requires all fields with indirections to be re-initialized with freshly allocated data instead of a postblit that is used during copying of a const object. (There will be no way to define such a const postblit, because the DIP assumes this to be useless.)

On 18/12/13 16:59, Timon Gehr wrote:
> It will be used to annotate a postblit that requires all fields with
> indirections to be re-initialized with freshly allocated data instead of a
> postblit that is used during copying of a const object. (There will be no way to
> define such a const postblit, because the DIP assumes this to be useless.)

Not sure I see the difference here with the existing different cases of const attached to a variable vs. const attached to a method.  The meanings are subtly different but the analogy is helpful.