PhobosWatch: manifest => enum

"Jérôme M. Berger" jeberger at free.fr
Fri Dec 28 11:50:56 PST 2007


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

Walter Bright wrote:
> Jérôme M. Berger wrote:
>>>>     BTW, I think it was Janice who suggested that the compiler should
>>>> know whether a constant needs to be manifest or not (depending on
>>>> whether its address is taken somewhere). This would remove the need
>>>> for a way to distinguish manifest constants explicitly. Any thoughts
>>>> on that?
>>> 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.
> 
> This is where we start to see a problem if we don't type const(int)
> differently from int - we no longer have a straightforward rule of what
> the type of &x is. This may not seem consequential in trivial cases, but
> when you start having more complex generic code, things can get
> maddening. C++ tries to have it both ways, leading to startling
> complexity in the language definition, and a lot of intractable problems
> cropping up in metaprogramming.
> 
	I agree that "const (int)" and "int" should be different types.
What I don't really see is why manifest constant need to be "int"
rather than "const (int)". After all, any attempt to use one as
non-const will fail (or should) so there's no real reason that they
can't be "const (int)", is there?

		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)

iD8DBQFHdVOgd0kWM4JG3k8RAoKRAJ0SeQvVUmcwputyeK6YImrMm4EiIACgrTjQ
Mvv9xUyUjcG8CY5w+7u0+cc=
=lJgZ
-----END PGP SIGNATURE-----



More information about the Digitalmars-d mailing list