 |
lua-l archive |
|
|
||
|
Despite the disappointed reactions on the above message so far, I for one couldn’t care less. In 10+ years of using Lua I got bitten only once by a bug because of a nil-in-table. How awkward it initially may be, once you get used to it, you hardly ever need nil-in-table constructs anyway, and in those few cases it is easy to work around.
> On 29 May 2018, at 18:53, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>
>> Just musings, but... I hope they get in, and I hope that `lua_keyin`
>> as well as the potential hypothetical `lua_keyvalue` include versions that
>> get integers and fields for number / string arguments directly (as well as
>> their raw version), making for a full suite that allows maximum performance
>> and mimics the current Lua C API structure:
>>
>> [...]
>
> We have decided that, at least for 5.4, we are not going on with
> the nils-in-table proposal. Although we really like the idea, the
> compatibility problems seem too big. As this message evidentiates again,
> the language would need a lot of extra stuff (metamethods, API calls,
> etc.), even when the option is off.
>
> -- Roberto
>
Imho the only thing it will fix is “initial expectations of newcomers”. And since that will always be a one-off cost, it is not worth the recurring costs (performance/runtime costs).
Thijs