lua-users home
lua-l archive

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


It was thus said that the Great Thijs Schreijer once stated:
> 
> > 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.
> 
> 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.

  In the 9 years I've been using Lua, a nil-in-table has only bitten me once
(and not even then because it miraculously worked!) which was an easy fix on
my part---replace nil with false (and because I was using 'not foo[idx]' for
checking, even less code had to change).

  -spc