config const n = 100000; // override default using ./a.out --n=<val>
Automatic translation of command line arguments to variables is useful (I have implemented this in shell scripts past as a nicer alternative to getopts). But the variables which receive command line overrides should be set apart in some way for that purpose.
Like by calling them "config" variables?
To specify values that must be known at compile-time, Chapel uses the 'param' keyword, where 'config param' symbols can be set on the compiler's command-line (as can 'config type' symbols, used to specify type aliases). 'param's and 'type' symbols tend to lead to compile-time specialization, similar to C++ template variables.
That just leaves 'config var' which indicates that a symbol can be set on the execution-time command-line and re-assigned over its lifetime.
If someone were to patch your C# compiler such that it didn't substitute, and instead pulled from a read-only memory location, would it in any way harm the correctness of your code?
In C# you can't assign a const to a value not known at compile time for this very reason. However, you can assign a variable value to a static readonly field.
RAAI: Really, assignment ain't initialization.
A file scope const object in C can have a value which is not known at the point of declaration.
extern const int var;
static const int var;
In this situation, though, the static value can be propagated as a true literal constant into code which precedes the point where the value is known. Just not in a "one-pass compiler".
This is also the case when a block-scoped const is initialized with a literal constant:
{ const int x = 5; /* almost "true" constant */ ... }