Can enum and immutable be unified?

[Robert Fraser]

Don wrote:
> 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.

I would _love_ to see being able to use another (MS?) linker on WIndows