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