const again

[Denton Cockburn]

On Thu, 06 Dec 2007 21:44:09 -0500, sambeau wrote:

> Bill Baxter Wrote:
> 
>> 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
> 
> how about replacing 'enum' with 'def'
> 
> def X { A, B, C }
> def { A, B = 5+7, C, D = 8, E }
> 
> def int A = 0;
> def int B = 1;
> def int C = 2;
> 
> def x = 3;
> def long y = 4;
> 
> Then we aren't changing the implementation, just the semantics so that
> they fit the implementation better.
> 
> ... thoughts?

You've mentioned this already, but D's already got too many keywords.  I 
think enum/macro is fine if it's explained in the docs.

Let's not add more keywords, esp. for minimal net benefit.