PhobosWatch: manifest => enum

[Walter Bright]

Jérôme M. Berger wrote:
> 	OK, I see your point, but like Bill said I think the issue here is
> with the "auto" type inference rather than the "const". What is
> needed is for "auto" to be smarter than it is now, namely:
> 
>  - for atomic types, strip the const;
>  - for pointers, if the language supports head const, then strip the
> tailmost const (ie make a mutable pointer to const data) otherwise
> keep the const;
>  - for classes, keep the const;
>  - for struct, the compiler already keeps track of whether the
> struct contains pointers or not because of the GC, doesn't it? In
> that case, if the struct contains pointers keep the const, and if it
> doesn't strip it (1);
>  - in all cases, allow a "const auto" statement to force an "auto"
> declaration to be "const". This would work even if the right hand
> expression is not "const":
> 	int x = 42;
> 	const auto y = x;       // y is now "const int"

I did think of doing that way, but:

1) it's too complicated to explain, too many special cases

2) Andrei pointed out to me that now the const-ness of a struct can 
depend on its private data types. This would suck for users, as private 
data is supposed to be opaque to users.