Non-enum manifest constants: Pie in the sky?

bearophile bearophileHUGS at lycos.com
Wed Nov 25 06:29:10 PST 2009


Nick Sabalausky:

> 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).

I think this is not so easy to do.

If the expression is a function the compiler has to be able to decide to see it as a compile-time function or as a normal function. Currently D2 never takes such choice, to keep the compiler simple, and the compilation time predictable and small. 

"except for the places where it's pointer or reference is taken": I think you meant "its". LLVM is able to do this when you use link-time optimization, but I think currently DMD isn't able to (unless some more logic is added to the middle layer of DMD. See the post of mine about D compiler layers that I'm about to post), so you will end with DMD managing all manifest constants as readonly variables, keeping them in the binary.

The current design that tells apart read-only (single-assiment?) values from true (manifest) constants is simpler to implement and in practice does't look like a big burden for the programmer (it's just a little extra complexity), so I can live with it, even if it's something that a good compiler is supposed to do by itself. Manifest constants can even be deprecated in future, once a default implementation of D2 uses a better back-end like LLVM.

But I'd like a better naming of those; this is doable and doesn't require lot of work (once the name change is done you can use a search&replace to fix Phobos). Half the battle was to use the "immutable" keyword instead of "invariant", but the work isn't finished yet :-)

Bye,
bearophile



More information about the Digitalmars-d mailing list