Re: [PATCH] setmetatable({}) causes error

[Dirk Laurie <dirk.laurie@...>]

2017-07-13 23:11 GMT+02:00 Andrew Starks <andrew@starksfam.org>:
>
> On Thu, Jul 13, 2017 at 11:32 Viacheslav Usov <via.usov@gmail.com> wrote:
>>
>> On Thu, Jul 13, 2017 at 6:12 PM, Roberto Ierusalimschy
>> <roberto@inf.puc-rio.br> wrote:
>>
>> > I hope you do not expect that the previous sentence ("Parameters act as
>> > local variables that are initialized with the argument values") applies also
>> > to C functions.
>>
>> In fact, at some point back in the past, that is exactly what I expected.
>> I expected that an omitted argument would be seen as nil in a C function. I
>> learned the actual behaviour only when I had to chase some subtle bugs
>> introduced by my expectation. I did not like the experience. That is why I
>> called that arcane and confusing.
>>
>> Another problem is that your language above implies that we somehow must
>> expect that setmetatable should behave like a "C function" and not a like a
>> Lua function. Why? I do not think "because it is implemented in C is a
>> sensible answer for someone who has no idea about the implementation of Lua.
>> And why, indeed, should we expect that C functions behave differently? The
>> difference is explained very compactly at the end of section 4.3, but it
>> only makes sense for a C programmer, not for a Lua programmer (a pure Lua
>> programmer would not even look there), who still sees there "virtual type
>> LUA_TNONE, which behaves like a nil value". Does that imply that every user
>> of Lua should understand the arcane details of Lua's C language API? I think
>> that would be too much to expect.
>>
>> > Similarly for the next sentence ("A vararg function [...] collects all
>> > extra arguments and supplies them to the function through a vararg
>> > expression").  So, I see no reason to expect that this particular sentence
>> > would apply to C functions.
>>
>> In fact, the behaviour of C functions can be most easily understood by
>> assuming they are always vararg. Even then the TNONE/TNIL difference
>> remains, but at least the "adjustment" is taken out.
>>
>> Cheers,
>> V.
>
>
> Your argument is completely valid. To be fair, it's pretty simple to create
> a Lua function that errors when an argument is omitted:
>
> (function(...) if select('#',...) <1 then error("no argument") end return
> "did stuff" end)() --errors
>
> It's much easier to do this on the C side, or at least it doesn't require a
> function call to select.
>
> I think the reason that the choice was made in this way is more of a matter
> of design. The thinking might be that by making sure that you have to use
> nil explicitly, you are forced to be more verbose about your intent.
>
> If it was done that way simply because it's a C function, then I think that
> is a good argument to be made in favor of a change to the Lua library, imho.
> If it's a design question, then patch away and use it in good health!

As has been demonstrated, it is not a Lua/C peculiarity whether
a missing argument is treated as nil. You can do whatever you prefer
in either language.

Personally I think it is quite reasonable for anyone to implement
a function to have whatever API they like, as long as it is documented.

So, the argument that the manual has

     setmetatable (table, metatable)

and not `setmetatable (table[, metatable])` is to my mind a clincher.

It is totally futile to argue otherwise; it's not going to change. The tiny
handful among us who actually bother to read the manual thoroughly
define "expected behaviour" = "documented behaviour". We _expect_
Lua to give an error message in cases like this. We have come to
rely on it. Working on a patched Lua in which it is perfectly OK to
omit arguments documented as being compulsory would confuse _us_.

-- Dirk