`const` variables cannot be declared in arbitrary order

[bbannier]

The general expectation in Spicy is that declarations can appear in any order. While as far as Spicy parsing and resolving is concerned this works for const variables as well, for out-of-order declarations we emit C++ which does not compile, e.g.,

const a = b;
const b = 1;
print a, b;

In this case we emit the constants like they appeared in the Spicy code which is not valid in C++ where all used identifiers need to be declared before,

namespace __hlt::foo {
    extern void __init_module();
    extern void __register_module();
    const ::hilti::rt::integer::safe<uint64_t> a = __hlt::foo::b;
    const ::hilti::rt::integer::safe<uint64_t> b = ::hilti::rt::integer::safe<std::uint64_t>{1U};
}

Note that this works for global variables since for them we still emit default-initialized declarations for them in a namespace, but only initialize them in __init_globals after the declarations. The following fails as well though for the same declaration-order issue:

const a = b;
global b = 1;
print a, b;

Tangentially related, we currently do not reject nonsensical cyclic const variables and then generate C++ which does not compile, e.g.,

const a = 1;
const b = a + c;
const c = a + 1;
print a, b, c;

Since we emit Spicy const values as C++ const variables they likely benefit more from C++ compiler optimizations than e.g., global variables, so I am not sure we would want to model const like global (but for mutability). We could consider instead disallowing const variables to be initialized by anything but literals or their combinations (I'd suspect this would also help users not run into some initialization-order footguns we have for globals).

[rsmmr]

We could consider instead disallowing const variables to be initialized by anything by literals or their combinations

That sounds reasonable to me.