PhobosWatch: manifest => enum

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

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

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
> 
	This is a problem whether x is a manifest constant or not: for
consistency with class/struct references and pointers, y should be
const. This is due to the fact that it is impossible to define a
mutable reference to a const class. So we have the following:

const MyClass o = new MyClass();
auto y = o;             // <= y must be of type const(MyClass)

	Which means that for consistency, the following should result in
const definitions of y1...y3 too:

enum { e = 42 }
const int var = 42;

auto y1 = var;
auto y2 = e;
auto y3 = 42;

	Since we work in the real world, we need to be pragmatic here. IMO
all three of these should result in mutable variables, as well as
the following:

const (const (MyStruct)*) s = new MyStruct;

auto y4 = s;            // <= y4 should be const (MyStruct)*
                        // ie mutable pointer to const data
                        // if such a beast is allowed by the
                        // language.

	And in that case, there's nothing that really prevents an object
from being a mutable reference to a const instance.

	If the whole head const / tail const debate gets us a language in
which we can't have a mutable pointer (or reference) to  const data,
then const-correctness means that y4 should be fully const (as well
as "auto" object references), but even so y1...y3 should be mutable.

	However, this has nothing to to with having the compiler detect
automatically if a const variable should be allocated or not. This
should be possible whatever the choice for "auto" variables.

		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)

iD8DBQFHdVs9d0kWM4JG3k8RAo0XAKCRO0C37/t0N7H8p8Cj8Zt63GDE7wCglC5L
wbRK7avBl1kwVSLU1Y9O5/0=
=SXv/
-----END PGP SIGNATURE-----