config const n = 100000; // override default using ./a.out --n=<val>
What? I smell anti-pattern. `const` should promise or specify to the compiler that this value doesn't change, so it can be baked into code.
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.
kenko is correct that the 'config' keyword is what indicates that a symbol can receive a command-line override in Chapel. As others have suggested, we followed C's lead in interpreting 'const' as "Cannot be re-assigned after initialization" rather than "Value must be known at compile-time."
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.
In C# it is exactly what it means. const values are substituted directly during compilation. This is why sometimes it makes sense to declare a variable as static readonly instead of const.
I'd argue that you are conflating implementation with semantics. The semantic meaning of const is 'this value will not change from here on out'. The C# compiler implements this by doing a substitution, but that is not mandated by nature of it being 'const'. Calling these variables 'config const' says 'this will be instantiated by some configuration parameter, but from here on it it will cannot change'.
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?
Actually I think it's the other way around. Since there is no guarantee that it is not copied, you can't assume either way. const means just that - const at compile time. As you say how the compiler chooses to utilize that information is up to the implementation.
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.
That's because of the implementation details of C#. If I make a const pointer in C, it's obviously not a compile-time value, because the memory location can't be guaranteed at compile time. Const values in C are definitely able to be assigned from variables. Very few languages share C#'s requirement that the assignment be known at compile-time (the only other one I can find is Nim).
Nitpick: (scoped) const variables in C can be initialized from run-time values, not assigned.
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;
This one is not known until either a definition is supplied later in the same translation unit, or else not until linkage with another translation unit which supplies a definition.
static const int var;
In this case, the value is not determined until either a definition is seen which provides an initializer, or else the the end of the translation unit is reached (whereupon the tentative definition becomes actual, with a value of zero).
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 */ ... }
In C, x isn't considered a constant expression, but de facto it is, which is good enough for optimizing.
It was an exception to your blanket statement (no language uses this definition of const). Apparently the only language that you consider relevant is C, which is fine. But I wouldn't take many cues from C in reference to modern language design and proper semantics. As useful as it is C has many holes and broken semantics.
Er, in both C and C++ it means that in static context for (at least) integral types, though it does also generate a symbol that can be used if needed (ie if you take its address).
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.