"bearophile" <bearophileh...@lycos.com> wrote in message news:hej7tb$k2...@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.)