luowy wrote:
the "IN" is a language feature,should high level and safe,k out of range return false is Intuitive,
instead of return undefined or runtime trap for these code as Chris point out:
Chris is right. The only option you have is to generate a TRAP.
Otherwise there would be an inconsistency with the compile time error message in case of
But I am not proposing to make any change at all. It is not worth the effort
and it must be seen in a bigger context. There are more such operations
that would need a check. Adding it to IN is too specific.
We have more important things to do. Look at the CPC changes list. We still have
about 40 unresolved items on it. We can come back to this topic in 1.8 if there is any need.
But then it must be discussed in a more general context, i.e. not only for IN.
The runtime check for array index bounds is of a completely different nature.
It guarantees that the memory is not corrupted which could otherwise lead to fatal
system crashes in the garbage collector or heap management.
The same applies to type guards. They are REQUIRED for technical reasons.
SET operations cannot destroy the memory outside the variable.
Memory integrity is the reason that forces runtime checks.
- Josef