That would also be better because I think I would expect this to yield a real Lua error:
print ( config.color?.style) --> config.color is a boolean false not a table
Because it would cause a real Lua error if config.color == true with your current approach, right? I think it should behave the same regardless of it being a true or false boolean.
So this is a feature shared by both the semantics I've proposed thus far. My original patch just feeds the current _expression_ into an OP_TEST, branching between the return expr case and the table get case in exactly the same way that Lua branches in response to an "and", "or", or "if". And that leads to a bit of a quirk, in that
(false)?.foo --> false
(nil)?.foo --> nil
(true)?.foo --> error: attempt to access a boolean value
The _SAFE userdata patch I'm proposing would handle things a little differently, specifically, it would imply:
(false)?.foo --> nil
The other two results would stay the same though. And to me, this feels like the "right" behavior. If I define Lua function like:
function draw_point(x,y,glowing)
Then I expect draw_point(x,y) to do the same thing as draw_point(x,y,nil) or draw_point(x,y,false). An optional flag should be considered to be "turned off" if it's defined as nil, false, or simply not sent to the function. Thus it makes sense to me that
draw_point_args.glowing?.color
should be an error if draw_point_args.glowing equals "true"; while if glowing is nil or false, I want that _expression_ to evaluate to nil or false. Whether (false)?.color equals nil, false, or behaves like a function that returns no value doesn't really matter to me; except insomuch that any patch should have a behavior that's easy to explain, and thus easy to anticipate in those cases where the difference between a nil and a false matters.
-Sven
