Re: Nil in table proposal

[pocomane <pocomane_7a@...>]

On Thu, Mar 22, 2018 at 1:07 PM, Hisham <h@hisham.hm> wrote:
> 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.

I wrote about this in the other mail, just to sum up: I think it is
better to reduce as much a possible the different behaviours between
the two modes. So I propose to call the metamethod both if the field
is missing or it is nil.

On Thu, Mar 22, 2018 at 1:07 PM, Hisham <h@hisham.hm> wrote:
> 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?

I found this a bit ugly too. Infact:

On Wed, Mar 21, 2018 at 2:00 PM, pocomane <pocomane_7a@pocomane.com> wrote:
> [1] This is for compatibility. If it was a completely new language,
> probably, I would use the keep-mode as the default.

Maybe in lua 6.0 ? :P

Being serious, the Roberto's obsarvation about the __gc, make me think
that using the keep-mode as default could rise the following issue.
All the tables used as keys of another one will never collected unless
one of the following happen
1) the container is deleted
2) the container is switched to normal-mode and the key/value is set to nil
3) the key/value is set to nil, then the table is switched to
normal-mode, then an iteration hit the key

The terrible thing is that the option 3) is the only avaialble If any
other reference to the key is lost (and the container needs to be
kept). This affects also the normal-mode-as-default: a table can be
switched to keep-mode and then it can be switched-back to the
normal-mode.

I am still thinking about this...