PhobosWatch: manifest => enum

[Bruce Adams]

On Fri, 28 Dec 2007 14:55:48 -0000, 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
>
> -Steve

That would seem to be a 'problem' with auto. Should auto inherit constness
or not?
i.e.

const int x = 5;
auto y = x;
y = 4; // legal or breaking const correctness?

The spec should say either:

1. auto always inherits constness (y is const)
2a. auto always throws away constness (y is not const)
2b. auto assigns the type but leaves const qualification to the user.
i.e.
  const auto y = x;
and
  auto y = x;

are two different declarations one const one not regardless of x.

Which is it now? and which makes most sense?
I'm not sure I like 1 as a typical usage might be to create a temporary  
for something that
is const and thus cannot be used directly. That said if x was a pointer  
rather than a POD type
it must absolutely inherit the constness so for constistency it must be 1.
Although, I can't help thinking that values and pointers/references can  
have different behaviour
because they are semantically quite different beasts.

Regards,
Bruce.