const again

[Derek Parnell]

On Thu, 06 Dec 2007 13:33:46 -0800, Walter Bright wrote:

> As a result of all the const comments here, and some serious semantic 
> problems discovered (dang it's hard to think of everything in advance), 
> it seems there needs to be another tweak of the const behavior.

I'm glad you're flexible ;-)

> So, we're going to try a new, simpler regime:
> 	const T x;
> is semantically identical to:
> 	const(T) x;
> and the type of x is const(T).

Which means for reference types, 'x' is modifiable but what it references
is not modifiable. And for non-reference types, 'x' is not modifiable. So
in some cases 'x' can be changed but in some cases it can't. Is that going
to be a problem?

   const int   x;  // Can't change 'x'
   const int[] y;  // Can change 'y' but not y[n]
 
> 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.

An additional requirement, I guess, was to avoid creating a new keyword. In
that case, the 'alias' keyword could also be overloaded to perform this
role.

   alias x = 3;
   alias long y = 4;
   alias real pi = 3.14159265358979;

especially in syntax forms that 'enum'  would have problems with ...

   alias {
     x = 3;
     long y = 4;
     real pi = 3.14159265358979;
    }

 
> There's one last problem:
> 	class C { }
> 	const(C)[] a;
> 	a[3] = new C();  // error, x[3] is const

I see, but in the new regime, doesn't this mean that both 'a' and what it
refers to are const? Or would that be written ...

     const ( (C)[]) a;

and thus what does this mean ...

     const (C[]) a;

To summarize, we can write ...

  const C[] a;
  const (C)[] a;
  const (C[]) a;
  const ((C)[]) a;

What will each of these forms signify?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
7/12/2007 9:44:43 AM