Non-enum manifest constants: Pie in the sky?

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:hej7tb$k21$1 at digitalmars.com...
> Nick Sabalausky:
>
>> Another good idea is like yigal said, just improve the optimizer so that 
>> any
>> immutables whose value is known at compile-time ends up effectively being
>> treated as a manifest constant. Then rip out enum's "enum x = 7;" syntax 
>> and
>> be done with it.
>
> One not written rule of D design seems to be that it must require a simple 
> and low-tech compiler. That's the only explanation I see for some of the D 
> design decisions that look silly if you think about having a good compiler 
> under it.
>

True, but the metaprogramming, or at least the CTFE, would seem to be a 
notable exception to that rule, and unless I'm missing something, that 
existing metaprogramming should be the only hard part needed for this 
immutable -> manifest constant idea. So since that metaprogramming is 
already in place, I would imagine it would be as simple as the compiler 
looking at any instances of "cast(immutable(Foo))blahExpression" or 
"immutable(Foo) foo = blahExpression" (and maybe even just "immutable foo = 
blahExpression;" allowing type inference?), then attempting to evaluate 
blahExpression at compile-time (which I believe it already does) and if it 
succeeds, then treat it as a manifest constant in any place where it's used 
(except for the places where it's pointer or reference is taken).

(Or something like that, I admit I'm still a D1 guy and don't have any 
actual experience using immutable, so might be misunderstanding something 
about how it's currently used.)