Re: Nil in table proposal

[Hisham <h@...>]

On 21 March 2018 at 10:17, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> 1) Garbage collection of the corresponding key. In your example, can
> 'a' be collected? (We can argue that this case follows from iteration:
> if 'a' appears in an iteration, it must be kept; otherwise, it could be
> removed.)
>
> 2) Metamethods: is 't[a]' "empty" for the point of view of calling
> metamethods? An access to t[a] should call __index? An assignment
> should call __newindex? (This is big difference and independent of
> iterations.)

Under pocomane's proposal, I would expect the behavior of metamethods
to follow from the table mode: for normal tables, the 5.3 behavior; in
keep-mode, a "stored" nil would be treated as an existing value, so
t[a] set to nil wouldn't trigger metamethods on access or update.

Another nice thing of this proposal is that for every existing Lua 5.x
program there is a statically-computable upper-bound of additional
memory that it would use if table constructors become nil-storing
normal-mode tables by default (often with probably no memory increase
at all on average, due to the delete-on-read/iterate semantics of
normal-mode).

The only downside is again the "JavaScript equality effect" [1]:
`keep{...}` would become the "right way" to collect arguments and the
obvious one would remain the "wrong way". Still an improvement over
select/table.pack, perhaps?

-- Hisham

[1] new form is introduced to do something with better semantics
(===), old one can't be removed/updated due to backwards compatibility
(==).