Re: A suggestion to allow return count optimization (mostly for the C API)

[Sergey Zakharchenko <doublef.mobile@...>]

Hello,

> I have came by a case where being able to determine the number of return values the caller of a particular function expects might be advantageous.

This sounds reasonable when what you return requires extra
computation/actions ... AND they are in some way ordered.

>  It clutters the parameters of a function with a value that can be provided implicitly,
> take(num, func, ...) in the base package, which calls a function "func", passing along the arguments, and returns at most "num" results (the rest shall not be filled with nils), and if numresults is smaller than "num", it shall be used instead (tail call return optimization).

This looks quite explicit and I doubt that tail call optimization
'spans' C function calls (you'll have to call func from C code,
right?) .

> debug.numresults(level) or a similar to retrieve the number of results from a particular call site

Having this in the debug library somehow decreases its usefulness. Why
would you want to obtain the number of results from any level other
than the reasonable one?

> Tail call return optimization - "function f(...) return g(...) end" should make lua_numresults return 2 in g on `local a, b = f()`, i.e. the number should be copied from the call site of the external function to the call site of the internal function (seems to be LUA_MULTRET at the moment).

AFAICT most of this trickery is to make the implicit return argument
count passing work. As much as I like this, if the computations
involved are really expensive, I'd rather pass an explicit argument
around saying which ones I want so that some minor refactoring doesn't
trip me further down the road. The usefulness of all of this breaks
down when you e.g. have a function returning a,b,c and want a and c
but not b. Passing around an explicit table like {a=true,c=true} is
simple and generic, and code says what you mean; table creation can be
lifted to avoid excessive garbage.

Best regards,

-- 
DoubleF

P.S. Nicol Bolas and Illidan... an epic StackOverflow discussion.