> A "missing" key *is* a value of nil. there is no difference. (unlike
> in JS where you can assign `undefined` which is treated differently to
> the `delete` operator)
Right, I know what the current behavior is. I was wondering if there was
consideration for adding a return value of `LUA_TNONE` of the new
shiny 5.3 APIs in 5.4, to indicate "key not found". That is, upon calling functions like
`lua_(raw)get(i/table/global)`, if the key you're looking for doesn't exist, you get back a `LUA_TNONE` return as an `int`, rather than just the nil type indicator. It would still push a `nil` (which would not break any older source code which checks for a nil value as failure and would avoid having to make a new 'undefined'/'none' literal in Lua).
That change might be too heavy-handed, of course, so just having a function `lua_getkey(i/table/global)` and then having this new API exhibit that behavior might be less of a breaking change and allow users of Lua to reason about 'nil' stuck in tables more effectively?
