However, simply reading _SAFE out of _ENV can't work well either. If we do that then the feature is prone to fail in odd ways anytime a programmer uses an unsuitable _ENV definition.
But, we can just have the version of _SAFE referenced by ? be _SAFE as it's defined in the global table. (Not _ENV._G, but rather the global table stored in the registry.) Implementing this requires adding a new opcode to the vm; and while that's something I usually try to avoid doing, in this instance, I'm feeling like it might be justified.
Thus, under my latest version of the patch (also now posted to the wiki), "a?.b" won't break after someone types "_ENV={}", but, it also won't slow down code that involves a lot of small chunks; i.e., you can't cause trouble by spamming "load("a=6")()".
The patch currently posted also allows upvalues named _SAFE to override the global _SAFE. Thus, you can locally change the operator's behavior (or just speed it up slightly), by defining "local _SAFE=_SAFE". (I'm not certain this feature is honestly a good idea -- but I can imagine cases where it would be useful.)
And it's now well past time for me to call it a night. It's been fun :) And the organization and readability of the language's source files continues to impress me.
-Sven
