Yes, I'm willing to admit that this may be case of over enthusiasm for a new idea :)
It does -- that's why I didn't seriously consider this approach earlier. But now that I've started thinking about it, I suspect that the real costs -- in terms of measurable increases in memory overhead and computation time, are likely to be negligible. Likewise, I suspect the size of the diff may actually be smaller than a less generic implementation. And because the patch would piggyback on OP_OR, rather than messing around with registers and bytecode by hand, it would be far more robust to language version changes.
Er, that's all well and good, but it looks like it won't do the "right
thing" by _default_ -- and I'd bet that 99% of potential uses are that
one...
Am I missing something important? I think the functionality I'm proposing now would be a strict superset of the functionality in the patch I originally posted. ?. and ?[ still work exactly as per my earlier suggestions -- chaining, in particular, should still work fine.
print( config.color? ) --> should print false not nil
This is the big potential drawback I can see for my _SAFE approach. While the syntax is shared with CoffeeScript's existential operator, the semantics are different. As I'm defining it, ? is a utility for safe table navigation -- it shouldn't be used to check for existence. "config.color?" is prettymuch guaranteed to never be nil or false, as it's just shorthand for "(config.color or _SAFE)".
That said -- I don't think implementing CoffeeScript's existential operator in Lua is actually a particularly good idea. Lua's conditional statements will treat anything other than a nil or false as "true", so having a CoffeeScript-style question mark that returns a boolean isn't terribly useful. CoffeeScript's semantics also get quite complex, exactly because they insist that the raw form of the operator have a boolean return value. In Lua, I don't think there's a need for that level of complexity. We have the option of taking a simpler, cleaner route.
-Sven
