PhobosWatch: manifest => enum
"Jérôme M. Berger"
jeberger at free.fr
Fri Dec 28 12:32:52 PST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Steven Schveighoffer wrote:
> "Janice Caron" wrote
>> On 12/28/07, 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
>> Oooh - I think I ought to say something here, since I was one of the
>> folk arguing that const(T) and const T should be interchangable.
>>
>> The thing is, I just don't see the problem. Given code like:
>>
>> const int x;
>> auto y = x;
>>
>> it should be possible to end up with x being a manifest constant,
>> unless the address is taken by some other piece of code somewhere
>> else. As I've mentioned before, x is not merely const, it's actually
>> /invariant/, despite the const declaration, because there is no
>> conceivable way for any piece of code anywhere in the program to
>> change it, ever (...except by doing stuff which is undefined,
>> obviously, but that doesn't count).
>>
>> And that's good, right? If the compiler is really smart, it might be
>> able to treat is as invariant(int). If not, treating it as const(int)
>> is harmless.
>>
>> But as for y...
>>
>> y is a /copy/ of x, and clearly it should be possible to make a copy
>> of a const thing and have the copy be mutable. Head constness needs to
>> be dropped here, exactly as it is dropped in template distinction in
>> D2.008 (t!(int) is the same thing as t!(const(int)) unless special
>> syntax is used).
>>
>> In fact, x is very much like a template, and could be implemented in a
>> similar way - don't instantiate it (allocate it storage space in the
>> ROM segment) unless it is referenced (its address is taken).
>>
>> I don't see why any of this isn't possible. Maybe that's because I'm
>> dumb and I'm missing something obvious, but I'm baffled as to what it
>> is. And if I /haven't/ missed anything, then we don't need a new
>> keyword /at all/ - be it enum, manifest, or anything else.
>>
>
> I don't disagree with you :) I'm merely clarifying Walter's gripe.
>
> I think there may be a better reason why your idea wouldn't work, but I am
> not sure how the compiler is implemented, so I can't really say much.
> However, it might be a problem when you are defining constants in one module
> to be used in other modules. How does the compiler know that those
> constants won't have their address taken somewhere else? When the compiler
> creates the object file, it has to assume since the symbol is public, it can
> have its address taken, no?
>
> If you had a specific D linker, you could modify the linker to take this
> into account, but that is not the case today.
>
You do it the same way it is done for templates (and in particular
for the associated type information data): you allocate it in each
module that uses it, but you put it in a special section that tells
the linker to merge duplicate definitions.
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)
iD8DBQFHdV10d0kWM4JG3k8RArGnAKCZomZsyJjTDsxLiu8BkIgb6SdzewCff3bx
Oi1ANAeonj5JW8M6JgbMcCs=
=8FdR
-----END PGP SIGNATURE-----
More information about the Digitalmars-d
mailing list