PhobosWatch: manifest => enum

["Jérôme M. Berger"]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Wright wrote:
> Jérôme M. Berger wrote:
>> 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?"
> 
	Yes and no: it would actually require the compiler to create a new
struct type that the programmer didn't request explicitly: ms1 would
be of type

struct {
    int value;
    const int* pointer;
}
SomeInternalStructTypeThatIsDifferentFromConstStructAndFromMutableStruct;

	This could cause lots of other issues like:

const MutableStruct ms2 = ms1;  // <= Error cannot convert
                                // implicitly, but it should.

	My suggestion wasn't perfect, but it should be reasonably
straightforward to implement in the compiler without introducing any
side-effects elsewhere (I hope).

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

	True, but since structs already exist, we're stuck with them so we
(well, Walter) must find a way to make const work with them.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger at free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger at jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHeCh/d0kWM4JG3k8RAj49AJ9LFyp+AbjjtyVsrgsyMHep0sm8jACfT2Ra
8txL7dsLXvbNoi+EmrbKqew=
=blb1
-----END PGP SIGNATURE-----