const again

[sambeau]

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?