PhobosWatch: manifest => enum

[Steven Schveighoffer]

"Janice Caron" wrote
> On 12/28/07, Steven Schveighoffer 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.
>

I don't disagree with you :)  I'm merely clarifying Walter's gripe.

I think there may be a better reason why your idea wouldn't work, but I am 
not sure how the compiler is implemented, so I can't really say much. 
However, it might be a problem when you are defining constants in one module 
to be used in other modules.  How does the compiler know that those 
constants won't have their address taken somewhere else?  When the compiler 
creates the object file, it has to assume since the symbol is public, it can 
have its address taken, no?

If you had a specific D linker,  you could modify the linker to take this 
into account, but that is not the case today.

-Steve