On 12/18/2013 05:05 PM, Joseph Rushton Wakeling wrote:
> 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.
>

Well, 'const' attached to a method is simply the notation used for attaching 'const' to the implicit 'this' parameter.

On Wednesday, 18 December 2013 at 15:20:39 UTC, Kenji Hara wrote:
> I think adding new keyword/attribute just for readability is overkill.
>
> Kenji Hara

We can use `unique` keyword as unique storage class of variables in future if we decide that this feature can be useful.
It's not my idea, see `std.exception.assumeUnique`:
"Checking for uniqueness during compilation is possible in certain cases (see the unique and lent keywords in the ArchJava language), but complicates the language considerably.".

We already have reserved `macro` keyword for AST macros, so add one more reserved keyword for possible language improvement is not so terrible. But, of course, it's only my IMHO.

On 18/12/13 18:20, Timon Gehr wrote:
> Well, 'const' attached to a method is simply the notation used for attaching
> 'const' to the implicit 'this' parameter.

Sure, but if you see a method:

   struct Foo
   {
       const int bar() { ... }
   }

... the instinctive interpretation of that is "This is a method that returns a const int."  You soon learn your mistake, but once you have, the mental association between one form of const and the other makes sense, even if you don't appreciate the subtlety of the fact that it's referring to the implicit "this" parameter.

I suggest attaching const, immutable, etc. to constructors is similarly helpful by analogy, even if it strictly speaking means using the same keyword for two different things.

On Wed, Dec 18, 2013 at 06:33:37PM +0100, Joseph Rushton Wakeling wrote:
> On 18/12/13 18:20, Timon Gehr wrote:
> >Well, 'const' attached to a method is simply the notation used for attaching 'const' to the implicit 'this' parameter.
> 
> Sure, but if you see a method:
> 
>    struct Foo
>    {
>        const int bar() { ... }
>    }
> 
> ... the instinctive interpretation of that is "This is a method that returns a const int."  You soon learn your mistake, but once you have, the mental association between one form of const and the other makes sense, even if you don't appreciate the subtlety of the fact that it's referring to the implicit "this" parameter.
[...]

For this reason, it is better to write 'const' on the right side of the function name than on the left:

	struct Foo
	{
		// Now it's clear(er) that 'const' refers to const(this)
		// rather than const(int).
		int bar() const { ... }
	}

And also to always write `const(int)` rather than the potentially ambiguous `const int`. It may feel unnecessarily verbose at first, until you have to distinguish between:

	const(int)[] func();
	const(int[]) func();
	int[] func() const;
	const(int)[] func() const;
	const(int[]) func() const;

then you begin to appreciate the notation. :)


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

On 18/12/13 19:40, H. S. Teoh wrote:
> For this reason, it is better to write 'const' on the right side of the
> function name than on the left

Yes, and it's exactly the practice I follow, although Ddoc replaces it on the left-hand side ... :-)

> And also to always write `const(int)` rather than the potentially
> ambiguous `const int`. It may feel unnecessarily verbose at first, until
> you have to distinguish between:
>
> 	const(int)[] func();
> 	const(int[]) func();
> 	int[] func() const;
> 	const(int)[] func() const;
> 	const(int[]) func() const;
>
> then you begin to appreciate the notation. :)

Well, quite :-)  I'm not complaining about the issues here, I'm suggesting that inventing an extra keyword for the cases discussed in these DIPs is not necessary, because the analogy and connection with existing use of const/immutable is valuable.

On Wed, Dec 18, 2013 at 08:09:54PM +0100, Joseph Rushton Wakeling wrote:
> On 18/12/13 19:40, H. S. Teoh wrote:
> >For this reason, it is better to write 'const' on the right side of the function name than on the left
> 
> Yes, and it's exactly the practice I follow, although Ddoc replaces it on the left-hand side ... :-)

I know, and IMO this deserves a bug in bugzilla. The idea behind Ddoc is very good, but there are quite a few areas in the current implementation that leaves one disappointed, and this is one of them. (I know I'm opening a can of worms here, since a good number of people prefer writing function modifiers on the left, but I feel strongly enough about this to bring it up. :P)


> >And also to always write `const(int)` rather than the potentially ambiguous `const int`. It may feel unnecessarily verbose at first, until you have to distinguish between:
> >
> >	const(int)[] func();
> >	const(int[]) func();
> >	int[] func() const;
> >	const(int)[] func() const;
> >	const(int[]) func() const;
> >
> >then you begin to appreciate the notation. :)
> 
> Well, quite :-)  I'm not complaining about the issues here, I'm suggesting that inventing an extra keyword for the cases discussed in these DIPs is not necessary, because the analogy and connection with existing use of const/immutable is valuable.

Yes.


T

-- 
Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder

On 12/18/2013 06:33 PM, Joseph Rushton Wakeling wrote:
> On 18/12/13 18:20, Timon Gehr wrote:
>> Well, 'const' attached to a method is simply the notation used for
>> attaching
>> 'const' to the implicit 'this' parameter.
>
> Sure, but if you see a method:
>
>     struct Foo
>     {
>         const int bar() { ... }
>     }
>
> ... the instinctive interpretation of that is "This is a method that
> returns a const int."  You soon learn your mistake, but once you have,
> the mental association between one form of const and the other makes
> sense, even if you don't appreciate the subtlety of the fact that it's
> referring to the implicit "this" parameter.
>
> I suggest attaching const, immutable, etc. to constructors is similarly
> helpful by analogy, even if it strictly speaking means using the same
> keyword for two different things.

Something that would be closer to what is happening here would be to make the 'const' annotation on a method denote purity.

On Wednesday, 18 December 2013 at 19:10:07 UTC, Joseph Rushton Wakeling wrote:
> Well, quite :-)  I'm not complaining about the issues here, I'm suggesting that inventing an extra keyword for the cases discussed in these DIPs is not necessary, because the analogy and connection with existing use of const/immutable is valuable.

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?

BTW, it looks like the DIP mix `const` and `unique` semantic. It's different things, but they are in the same section.

On 12/18/2013 08:09 PM, Joseph Rushton Wakeling wrote:
> On 18/12/13 19:40, H. S. Teoh wrote:
>> For this reason, it is better to write 'const' on the right side of the
>> function name than on the left
>
> Yes, and it's exactly the practice I follow, although Ddoc replaces it
> on the left-hand side ... :-)
>
>> And also to always write `const(int)` rather than the potentially
>> ambiguous `const int`. It may feel unnecessarily verbose at first, until
>> you have to distinguish between:
>>
>>     const(int)[] func();
>>     const(int[]) func();
>>     int[] func() const;
>>     const(int)[] func() const;
>>     const(int[]) func() const;
>>
>> then you begin to appreciate the notation. :)
>
> Well, quite :-)  I'm not complaining about the issues here, I'm
> suggesting that inventing an extra keyword for the cases discussed in
> these DIPs is not necessary, because the analogy and connection with
> existing use of const/immutable is valuable.

There is no such analogy or connection.

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.