Can enum and immutable be unified?

[Don]

Robert Fraser wrote:
> 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"

objconv can disassemble OMF now, but it can't yet convert COMDAT 
sections, so it can't convert them to ELF or COFF. Might not be so 
difficult, if someone wanted to do it. D's use of COMDATs is not so 
complicated.