const again

[Paul Anderson]

Walter Bright Wrote:

> 
> That leaves what to do about manifest constants. It occurs that we 
> already have a mechanism for them - enums. So why not:
> 	enum x = 3;
> 	enum long y = 4;
> ? I think that solves our problem.
> 
> There's one last problem:
> 	class C { }
> 	const(C)[] a;
> 	a[3] = new C();  // error, x[3] is const
> does not work with this new regime. Every twist we tried to make it work 
> caused other problems. Eventually, it just became clear that this just 
> is not going to work. But, the following does work:
> 	a ~= new C();
> 	a = a[1..3];
> 	a = b;
> just like for strings. One can copy, concatenate, and slice such arrays 
> (just like for strings). It's not so bad. Andrei also mentioned the 
> possibility of using a template:
> 	TailConst!(C)[] a;
> which would do whatever was necessary under the hood to allow the 
> elements of a to be rebound while still keeping the contents of the C 
> objects const.

I don't care for 'enum' used in this way. It distracts from (dilutes?) the meaning as an enumerated type.

How about final?

final x = 3;
final real y = 7.5;

'final' is already a keyword and it's already used to declare one flavor of const in Java.

Paul