const again

[Bill Baxter]

Paul Anderson wrote:
> 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
> 

That's not bad either.  final, alias, macro -- they all make more sense 
than reusing 'enum' for manifest constants that aren't really 
enumerating anything.

--bb