const again

[Walter Bright]

Janice Caron wrote:
> I understand the problem. Have you considered the possible solution
> which has been suggested on this group - a special syntax for classes
> having mutable refs to constant data? Under that suggestion, the above
> code would become:
> 
>         class C { }
>         const(C)&[] a;
>         a[3] = new C();  // OK
> 
> It's the ampersand that makes it OK. It tells you that the reference
> is not constified.
> 
> I think that would work, in exactly the same way that
> 
>         struct S { }
>         struct(S)*[] a;
>         a[3] = new S();  // OK
> 
> works.

There are a couple problems with it, the worst of which is its impact on 
generic code:
	const(T)[]
Would you put the & there or not? What would & mean if one wrote:
	struct S { C c; }
	const(S)&[] a;
? One principle we try to adhere to is that it should make sense to be 
able to wrap any type with a struct, and have it be possible for that 
struct to behave as if it were that member type.

And finally, this suggests that & means "tail-const". Tail-const has 
that severe problem that there is no such thing as a tail-const member 
function (i.e. a member function that can modify the fields of the 
object, but not anything those fields refer to).


> Anyway, like I said, I'm happy.

I'm glad!

> D is brilliant :-)