Can enum and immutable be unified?

[Robert Fraser]

Don wrote:
> Ary Borenszweig wrote:
>> Michiel Helvensteijn escribió:
>>  > Walter Bright wrote:
>>  >
>>  >> immutable - data that cannot change or be changed (imagine it is 
>> stored
>>  >> in ROM)
>>  >>
>>  >> const - read only view of data, you cannot change it but others can
>>  >>
>>  >> enum - compile time constant, has no storage
>>  >>
>>  >> The only place these overlap is in the declaration of symbolic
>>  >> constants. C++ has all three, but in a way that is context dependent
>>  >> that very few people are aware of.
>>  >
>>  > Aren't immutable and enum the same thing? At least to the programmer?
>>
>> Yesterday I was thiking the same thing. I think the only difference to 
>> the programmer between those is that you can take the address of 
>> something immutable, but can't take the address of a compile time 
>> constant.
>>
>> Now I wonder why would you like to take the address of something 
>> that's immutable. The times I remember passing something's address is 
>> to change it, something like:
>>
>> int x = 10;
>> foo(&x);
>> // now x might have changed
>>
>> But immutable variables cannot change, so no need to pass it by 
>> reference.
>>
>> The other usage is performance. If it's an immutable big struct you 
>> might want to pass it by reference instead of copying the whole thing. 
>> If you can't pass a reference to something immutable you couldn't do 
>> with this optimization. But in this case, the compiler could choose to 
>> rewrite mentions to big immutable variables as references to those in 
>> a transparent way to the programmer. Of course this is harder for the 
>> compiler writer, but it's much easier for the user.
>>
>> (as a starting point the compiler could do without this optimization 
>> and see if the users are having problems without it)
>>
>> I can't come up with other cases where you'd want to pass a reference 
>> to something immutable.
>>
>> So let's suppose we don't need to take an immutable varaible's 
>> address. We get rid of "enum" then and unify "immutable" and "enum" 
>> into the single "immutable" keyword. The compiler still has to 
>> determine what to put in ROM and what not. But I think this one is 
>> easy: primitive types can go in ROM, also maybe small immutable 
>> structs, maybe primitive arrays, but not classes or references to 
>> classes.
>>
>> Is there something fundamentally wrong with this reasoning?
> 
> AFAIK, the only reason 'enum' manifest constants exist in D2 is because 
> of linking limitations. OPTLINK isn't smart enough to be able to discard 
> immutable references. There's no need to use them, unless you have 
> something like the Windows headers, where they're an enormous bloat if 
> they aren't discarded. Most people should forget they exist.

Since objconv works with OMF now, how hard would it be to get a workflow 
going to use a different linker on Windows? Every other post these days 
seems to be "oh, it's an optlink issue"