I originally asked: "Is
Code: Select all
k := 33;
RETURN k IN {1}
The answer is clear to me now: Yes. But the bug is not in the compiler, it is in my code. Since there is no compiler bug we do not want to do anything for release 1.7, and can concentrate on more important matters.
However it has been observed that my bug is not obvious unless you are familiar with the small print of the language report. Common sense is not enough, as my code would be ok in Oberon.
A small change to the compiler would enable the system (Compiler & run-time) to detect this error quickly. This is helpful, but is it desirable?
I think that help with finding non-obvious bugs is desirable. This is particularly true here as the non-deterministic nature of the code (it depends on global state not directly in the buggy statement) means that even exhaustive testing is inadequate. The test results might be satisfactory today, but not so tomorrow.
Chris says it is undesirable because the programmer looses the option to disable the checks. Why would she do that? - To use out of bounds k; I no longer sympathise with that. To use in bound k FAST; I totally sympathise with that. We do not have timing information so we don't know just strong this argument is.
In conclusion: I think we should not change the compiler for release 1.7, but I would not be surprised if in time this turns out to be unfinished business.