On Thursday, 19 December 2013 at 11:22:59 UTC, Maxim Fomin wrote:
> void main()
> {
>    immutable int* ptr = foo();
>    writeln(*ptr); // it is 0
>    GC.collect();
>    writeln(*ptr); // it is 1 now
> }
>
> Your proposal suffers from same issue. Although idea of unique can be worthy, without escape analysis it is another hole.

Wow... that looks really unsettling.
But as far as I can tell, you are declaring an immutable pointer, and the pointer itself never changes. After all, this looks correct. Or am I missing something from the language specifics?

On 12/19/2013 02:27 AM, Kenji Hara wrote:
> 2013/12/19 Joseph Rushton Wakeling <joseph.wakeling@webdrake.net
> <mailto:joseph.wakeling@webdrake.net>>
>
>     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.
>
>
> That's right. When 'const' constructor/postblit is called, the
> constructing object qualifier is either mutable or immutable, even if it
> is not visible inside const constructor/postblit.
> ...


That is how to treat a 'wildcard', and not a supertype. The semantics of the new const constructor are the same as for the existing inout constructor.


> ----
>
> I tweaked the descriptions in DIPs, about Const Constructor/Postblit
> concept.
>
> - I mostly removed words "unique constructor" and "unique postblit",
> because they would just increase reader's confusion.
>    DIPs can describe intrinsic concepts without these words.
>
> - I added following sections in DIPs:
>
>    Why 'const' postblit will called to copy arbitrary qualified object?
> http://wiki.dlang.org/DIP49#Why_.27const.27_postblit_will_called_to_copy_arbitrary_qualified_object.3F
>
>    Why 'const' constructor will be called to create arbitrary qualified
> object?
> http://wiki.dlang.org/DIP53#Why_.27const.27_constructor_will_be_called_to_create_arbitrary_qualified_object.3F
>
>    There's no violation against the widely known "const method" concept.
>
> Kenji Hara

Well, a constructor can be thought of as yielding a result. A const method returning 'this' cannot return an 'immutable' object. I do understand your rationale. What I am saying is that the DIP adds a wildcard meaning to 'const' that was not previously there, and I consider this to be more of a weakness than a strength.

2013/12/19 Timon Gehr <timon.gehr@gmx.ch>
>
> Well, a constructor can be thought of as yielding a result. A const method returning 'this' cannot return an 'immutable' object.


Constructor has no return value in semantic level.


> I do understand your rationale. What I am saying is that the DIP adds a wildcard meaning to 'const' that was not previously there, and I consider this to be more of a weakness than a strength.
>

What is the weakness? As far as I can see, there is no *logical* failure.

Indeed I can agree that the described concept in the DIP may be hard to understand, but it would be enough easy compared with the currently implemented thing.

Kenji Hara

On 12/19/2013 02:58 PM, Kenji Hara wrote:
> 2013/12/19 Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>>
>
>     Well, a constructor can be thought of as yielding a result. A const
>     method returning 'this' cannot return an 'immutable' object.
>
>
> Constructor has no return value in semantic level.
>

Conceptually speaking, a struct constructor declaration immediately gives you a callable with the corresponding return type.

struct S{ this(int x)immutable{ } }
immutable(S) construct(int x){ return S(x); }


>     I do understand your rationale. What I am saying is that the DIP
>     adds a wildcard meaning to 'const' that was not previously there,
>     and I consider this to be more of a weakness than a strength.
>
>
> What is the weakness? As far as I can see, there is no *logical* failure.
>
> Indeed I can agree that the described concept in the DIP may be hard to
> understand, but it would be enough easy compared with the currently
> implemented thing.
>
> Kenji Hara

I think it is easy to understand. I just think that the 'const' qualifier is not descriptive.

2013/12/20 Timon Gehr <timon.gehr@gmx.ch>

> On 12/19/2013 02:58 PM, Kenji Hara wrote:
>
>> 2013/12/19 Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>>
>>
>>
>>     Well, a constructor can be thought of as yielding a result. A const
>>     method returning 'this' cannot return an 'immutable' object.
>>
>>
>> Constructor has no return value in semantic level.
>>
>>
> Conceptually speaking, a struct constructor declaration immediately gives you a callable with the corresponding return type.
>
> struct S{ this(int x)immutable{ } }
> immutable(S) construct(int x){ return S(x); }
>

It's not necessary concept.

     I do understand your rationale. What I am saying is that the DIP
>>     adds a wildcard meaning to 'const' that was not previously there,
>>     and I consider this to be more of a weakness than a strength.
>>
>>
>> What is the weakness? As far as I can see, there is no *logical* failure.
>>
>> Indeed I can agree that the described concept in the DIP may be hard to understand, but it would be enough easy compared with the currently implemented thing.
>>
>> Kenji Hara
>>
>
> I think it is easy to understand. I just think that the 'const' qualifier is not descriptive.
>

I think it is necessary small learning cost, to keep language semantics simple.

Kenji Hara

Kenji Hara:

> I think it is necessary small learning cost, to keep language semantics simple.

The semantics of the language is not simpler using "const", it's the same semantic complexity. But it's a little less clear for the person that reads the code.

Bye,
bearophile

On 2013-12-18 03:42:38 +0000, "Kenji Hara" <k.hara.pg@gmail.com> said:

> 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

I can't help but notice that if you want class-typed members to be assignable in a "this(this) immutable" context you'll need to add tail-constness for classes in the language.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Thursday, 19 December 2013 at 12:49:55 UTC, Francesco Cattoglio wrote:
> On Thursday, 19 December 2013 at 11:22:59 UTC, Maxim Fomin wrote:
>> void main()
>> {
>>   immutable int* ptr = foo();
>>   writeln(*ptr); // it is 0
>>   GC.collect();
>>   writeln(*ptr); // it is 1 now
>> }
>>
>> Your proposal suffers from same issue. Although idea of unique can be worthy, without escape analysis it is another hole.
>
> Wow... that looks really unsettling.
> But as far as I can tell, you are declaring an immutable pointer, and the pointer itself never changes. After all, this looks correct. Or am I missing something from the language specifics?

Actually it is fully immutable, which means that both pointer and pointee are fixed. This is not the case and that's why it is a hole.

On Thursday, 19 December 2013 at 15:32:33 UTC, Kenji Hara wrote:
> I think it is necessary small learning cost, to keep language semantics
> simple.
>
> Kenji Hara

If that is an extra learning cost, doesn't it make the semantic more complex, almost by definition ?

I'm also against adding a new meaning to const, especially when its current meaning can make sense.

2013/12/20 Michel Fortin <michel.fortin@michelf.ca>

> On 2013-12-18 03:42:38 +0000, "Kenji Hara" <k.hara.pg@gmail.com> said:
>
>  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
>>
>
> I can't help but notice that if you want class-typed members to be assignable in a "this(this) immutable" context you'll need to add tail-constness for classes in the language.


Sorry I can't understand what you saying. DIP49 does not touch class reference semantics. It's not a purpose of DIP49.

Kenji Hara