Meaning of const

Timon Gehr timon.gehr at gmx.ch
Wed Jan 25 14:50:57 PST 2012


On 01/25/2012 02:29 AM, H. S. Teoh wrote:
> On Tue, Jan 24, 2012 at 08:01:41PM -0500, bearophile wrote:
>> Jonathan M Davis:
>>
>>> Now, the confusing part is the fact that unlike C++, D allows you to put the
>>> const for making the function on the _left-hand_ side of the function (C++
>>> only lets you put it on the right). This is to increase consistency between
>>> modifers (public, override, pure, etc.) - they _all_ can go on both the right
>>> and left (which is very unfortunate in the case of const and immutable IMHO).
>>> That means that const (and immutable) always modify the function rather than
>>> the return value unless you use parens.
>>
>> Some time ago we have discussed this topic in an enhancement request in Bugzilla. The idea was to disallow code like:
>>
>>
>> struct Foo {
>>      int x;
>>      const const(int) bar() {
>>          return 0;
>>      }
>> }
>> void main() {}
>>
>>
>> and require the struct "const", "immutable" to be only on the right if present.
>> Walter shot this idea down for consistency. But I generally don't want
>> consistency when it's just a potential source of confusion for the
>> programmer :-)
> [...]
>
> How can this be consistency? For example:
>
> 	class A {
> 		const int x;
> 		@property const int y();
> 	}
>
> Now you have typeof(A.x)==const(int) and typeof(A.y)==int. Seems quite
> inconsistent to me.
>
> But since Walter doesn't like the idea of restricting the syntax to 'int
> y() const', then what about making it mandatory to write:
>
> 	const(int) x;
>
> instead of:
>
> 	const int x;
>
> ?

You essentially propose to remove the const/immutable/shared/inout 
storage classes for variables. It would break almost every D program and 
I don't see many benefits.
>
> Requiring the parentheses is a bit extreme, I admit, but it touches upon
> another area of D syntax that I don't quite like, and that is const or
> immutable applied to arrays:
>
> 	const(int)[] x;		// array of const(int)
> 	const(int[]) x;		// const array of int
> 	const int[] x;		// ??? const array of const int? Or one
> 				// of the above?

const(int[]).


The storage class of a declaration applies to the whole declaration.
>
> It gets worse when you throw in ref:

Ref does not change anything but the calling convention *of the 
function*. The reference itself cannot be rebound, there is no syntax 
for it.

>
> 	ref int f();		// returns int* (I think?)
> 	ref const(int) f();	// returns const(int)* (?)
> 	ref const int f();	// ???
> 	const ref int f():	// ???
>
> The last line is quite bad. Is the return type const(int*) or
> const(int)*, or is it just int* (i.e., const applies to f not the return
> value)?

It is int.

>
> 	ref const(int)[] x;	// ref to array of const(int)?

Note that ref can only be on a function or on a parameter.

> 	const(ref int)[] x;	// array of refs to int?

No such thing exists.

> 	const ref int[] x;	// array of ???

const(int[]). Declaration is invalid, would have to be a parameter.

> 	const ref int[] x();	// const function that returns ref int[]?

It returns int[], by reference. It is equivalent to

int[] x()const ref;

Though most people will prefer to have 'ref' on the lhs:

ref int[] x()const;

It still applies to the function though.

> 	const const ref int[] x();	// const function returning what?

Redundant storage class const.

ref int[] x()const const; is the same thing.

>
> The more I think about this, the more confusing it becomes.

It is very simple. What may be confusing you is that 
const/immutable/shared/inout are both type constructors and storage classes.

> If
> parentheses were mandatory after const, things would be much, much
> better:
>
> 	const(ref int) x;
> 	const(ref const(int)) x;
> 	... etc.
>
> Much clearer to me.

It is not to me. This is not valid syntax. Also, types of the general 
form const(...const(...)...) don't make a lot of sense. Const is transitive.



More information about the Digitalmars-d-learn mailing list