PhobosWatch: manifest => enum

[Christopher Wright]

Jérôme M. Berger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Walter Bright wrote:
>> What do we do with:
>>
>>     const MyInt m = 3;
>>     auto n = m;
>>
>> Does n get const or not? If it is, now it is behaving differently from
>> other types, and so is not a plug-in replacement. If it does not, what
>> happens if MyInt has a pointer member? Suddenly, the const gets stripped
>> from the pointer, and there is no const-correctness.
> 
> 	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"
> 
> 		Jerome
> 
> (1) It would be even nicer if the compiler could keep track of
> whether there are *mutable* pointers in the struct and strip the
> "const" from the "auto" variable if all pointers in the struct are
> "const" anyway, so it wouldn't break const-correctness:
> 
> struct {
>    int value;
>    const int* pointer;
> } ConstStruct;
> 
> struct {
>    int value;
>    int* pointer;
> } MutableStruct;
> 
> const ConstStruct   cs0;
> const MutableStruct ms0;
> auto cs1 = cs0;         // <= cs1 is a ConstStruct since all
>                         // pointers inside are const anyway.
> auto ms1 = ms0;         // <= ms1 is a const MutableStruct.

That doesn't really make sense. You could push off const one level:
ms1.value = 3;          // Fine
*ms1.pointer = 3;       // Error; pointer is const

That would make sense, but it would be hard to do, and it would be hard 
for a programmer to think "okay, I just did this assignment, now what is 
const in the struct and what isn't?"

Structs make const hard. It'd be easier with just classes, I think.