PhobosWatch: manifest => enum

[Janice Caron]

On 12/28/07, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> ""Jérôme M. Berger""  wrote
> > Walter Bright wrote:
> >> The reason this won't work is because:
> >>     const int x = 3;
> >> will type x as const(int), not int. There needs to be a way to declare a
> >> constant of type int.
> >
> > Er, why? Taking "&x" should return a "const (int)*" and using "x"
> > directly should always work so long as you don't modify it. Are you
> > telling us that the following code will fail:
> >
> > void func (int param)
> > {
> > }
> >
> > const int x = 42;
> > int y = x;              // <= This should work
> > func (x);               // <= This should work too
> >
> > Or is there something I'm missing here?
>
> I agree with everything you are saying, except I think Walter is thinking of
> the case:
>
> const int x;
> auto y = x;  // y is now const

Oooh - I think I ought to say something here, since I was one of the
folk arguing that const(T) and const T should be interchangable.

The thing is, I just don't see the problem. Given code like:

    const int x;
    auto y = x;

it should be possible to end up with x being a manifest constant,
unless the address is taken by some other piece of code somewhere
else. As I've mentioned before, x is not merely const, it's actually
/invariant/, despite the const declaration, because there is no
conceivable way for any piece of code anywhere in the program to
change it, ever (...except by doing stuff which is undefined,
obviously, but that doesn't count).

And that's good, right? If the compiler is really smart, it might be
able to treat is as invariant(int). If not, treating it as const(int)
is harmless.

But as for y...

y is a /copy/ of x, and clearly it should be possible to make a copy
of a const thing and have the copy be mutable. Head constness needs to
be dropped here, exactly as it is dropped in template distinction in
D2.008 (t!(int) is the same thing as t!(const(int)) unless special
syntax is used).

In fact, x is very much like a template, and could be implemented in a
similar way - don't instantiate it (allocate it storage space in the
ROM segment) unless it is referenced (its address is taken).

I don't see why any of this isn't possible. Maybe that's because I'm
dumb and I'm missing something obvious, but I'm baffled as to what it
is. And if I /haven't/ missed anything, then we don't need a new
keyword /at all/ - be it enum, manifest, or anything else.