Open bradcray opened 5 years ago
My intuition here is to consider this a bug and to give an error if the types of a config's code-based initialization and command-line based initialization differ (or, perhaps, the latter isn't coercible to the former).
I suspect this originates, at least partly, with my experience which led to d3113b7b. In the aftermath of that I've decided this really is a feature, just one whose subtleties might not be fully appreciated. As such I don't think I want us to make it an error and thus outlaw it. But a warning might be worthwhile, perhaps something like 'command-line initialization changes the type of runSecs'. If I've thought this through right, I think we'd want to emit the warning if any type coercible to the type implied by the source code was not coercible to the type implied by the compiler command line initializer. Or in other words, if the compile-time initialization made some execution-time command line setting for the config illegal, where it would have been legal before.
When a
config const
orconfig var
has its value set at compile-time, the expression it's set to is essentially dropped into the Chapel code as its initializing expression. This can result in surprises. For example, given:if the user compiles with
-sn=100
thenn
will be inferred to be an integer rather than a real. This is part of the power of setting configs at compile-time (general expressions can be put into the code), but also represents a potential point of confusion or errors (the programmer obviously thought ofn
as a real).This could be prevented by coding defensively:
but it seems unfortunate to recommend that programmers use types in this way for safety in a context where they're often left out for conciseness.
On the other hand, this behavior could also be considered a powerful feature since to change a 64-bit config real into a 32-bit real, I could compile with
-sn=1.5:real(32)
rather than the more involved:and then compiling with -sntype=real(32).