[hogliux]

Because with a constexpr declaration everything will be constexpr, i.e. you couldn't modify the values at run-time.

The idea here is that finding the storage of the value is done at compile-time, but the values themselves are run-time values.

[gumby]

Thanks, I wasn't very clear but now I see the problem. The C++ invocation syntax (basically the difference between expressions and statements inherited from Algol) makes it impossible to call if you want to update it at runtime.

You could declare `static static_map<>::Value& get()` constexpr. (Actually you wouldn't need to; I think you could simply declare `semi::map<>::get()` to be constexpr) and I believe it would allow calling to look up a value to inlined at compile time.

However using it as an lvalue isn't possible with current c++ syntax. As a long time Lisp programmer this limitation continually trips me up.

Sorry about the backquotes; I know that HN doesn't use MD but it was the simplest way to denote code inline.

[hogliux]

Hmmm, I'm not sure I understand. You can't really mark `static static_map<>::Value& get()` constexpr because it returns a value which is only known at run-time - again the value is a run-time value, only the lookup (where in memory) is at compile-time. This has nothing to do with inlining.

[gumby]

Ahh, I looked in the source and see that runtime_map is simply a std::unordered_map.

I didn't look closely enough and assumed you'd made your own hash lookup so that parts of it could be run at compile time (in fact you could intern compile-time keys statically in the front of an object (in the initialized data section of the object file) adding a single additional probe at runtime) and let the linker patch up the locations in the usual fashion.

This is all a move in the right direction!