Re: Performance problem with table.move

[Viacheslav Usov <via.usov@...>]

On Mon, Dec 7, 2020 at 11:30 PM Egor Skriptunoff
<egor.skriptunoff@gmail.com> wrote:

> The Lua manual does not restrict the use of nil in Lua programs (except table length operator).

I did not say anything about restrictions. But, even then, you say
that it does not restrict, with "except" following immediately. And
then you talk about "subjective opinion'?

> How do you decide when using nil is "good" and when it is "not good"?

I did not decide. Any pair of distinct values could have been used to
formulate your problem, and it was you who demonstrated that nil was
not a good choice.

Still, if you want my opinion, I will say that the use of nil was not
an obviously good choice if one supposes that the problem was at least
remotely practical, which would require some use of the output.  With
strings of nils, the length operator is not defined, nor is iteration
"in order" via ipairs(), and one would need auxiliary code if that
were needed.

> Your question implies that a restriction on usage of nil should exist in Lua.

Again, I did not talk about "restrictions", but we may have a
linguistic issue here. The manual says that:

[Tables] can contain values of all types (except nil). Any key
associated to the value nil is not considered part of the table.
Conversely, any key that is not part of a table has an associated
value nil.

Your posture as if nil were a regular value that could be used like
any other is untenable.

> It is obvious from the benchmark of program #2 vs program #4 in the OP.

If "OP" refers to your first message in this thread, then I should say
that program #4 was not listed there, and it is not obvious that your
suggestion "We need something like table.rebuild()/table.new() in Lua
to avoid inserting fake values" is of any relevance. Then, some recent
messages in the thread offer better performance than of program #4,
without dependency on your suggestion.

Cheers,
V.