Re: Oddity with tinsert (Lua 4.0)

[Reuben Thomas <rrt@...>]

> I bet there are many other functions which have similar
> behavior. What we would really need is a document
> describing exactly what behavior the standard library
> functions should conform to in cases such as this.

??! We do have such a document: the user guide.

> A similar situation could occur if you passed LESS
> parameters to a function than it expected.
>
> tinsert(t, 3)
>
> would probably set the 3rd parameter to nil, which
> isn't exactly obvious.

What???! tinsert(t, 3) adds "3" to the end of the list.

> I wouldn't really call this a bug either.

Of course it is a bug. The function is not working as described in the user
manual. The only argument I can see against this is that perhaps C functions
should not be expected to adjust their arguments in the same way as Lua
functions, but that introduces a subtle and dangerous asymmetry; besides, I
override many of the standard C functions with my own Lua wrappers, so how
am I to know in general whether I'm calling a C or Lua function?

> passing an incorrect number of arguments to a
> function. One could probably argue that it should
> in fact take the last argument instead of the 3rd.

There is no argument. There is a specification in the user manual to which
the implementation does not conform.

> Not that this changes anything, but it 4.1
> I believe you could simply:
>
> tinsert(t, 3, (gsub(...)) )

Indeed, but this shouldn't be necessary.

-- 
http://sc3d.org/rrt/ | free, a.  already paid for (Peyton Jones)