lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Fri, Jun 1, 2018 at 6:21 AM, Thijs Schreijer <thijs@thijsschreijer.nl> wrote:


> 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
>

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.

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

Well I've been at this for three years now and it's still a PIA for me and all the people that want to see an array data type. I *hate* having to use arrays in _javascript_, but I guess I'll have to throw my hat in that ring. NIL_IN_TABLE seems like a pretty minor compromise for allowing predictable sequences. 

Russ