support variable number of return values in function conversion

[belm0]

Regarding converting D functions for use in Lua, while return of multiple values is supported, it doesn't appear possible to return a variable number of values. Variable return value count is used often in Lua API's. I understand it can be done from the C API, but I'd argue that the function converter should support this for convenience and consistency.

On the related topic of multiple return types, I'm questioning the use of static arrays (in addition to tuples). It's adding magic for a limited use case-- how often do you return multiple values of the same type? And what's wrong with using tuple in that case-- e.g. "tuple(5, 10)"?

I have a proposal to address both of these:

• define an attribute which signals that a function's return value of type T[] should be unpacked into multiple values
• improve std.variant conversion so that we can use Variant[] as return type
• remove static-array-return special case from the function converter (tuples are still useful for extra compile-time bug coverage and performance when there are a fixed number of values)

So as long as a D function is tagged with the attribute, you could return a variable number of arguments via a dynamic array. If the values need to have different types, use Variant[]. The attribute still works with static arrays too, of course.

[JakobOvrum]

Regarding converting D functions for use in Lua, while return of multiple values is supported, it doesn't appear possible to return a variable number of values. Variable return value count is used often in Lua API's. I understand it can be done from the C API, but I'd argue that the function converter should support this for convenience and consistency.

The issue is just coming up with a neat, safe and efficient way to do it.

On the related topic of multiple return types, I'm questioning the use of static arrays (in addition to tuples). It's adding magic for a limited use case-- how often do you return multiple values of the same type? And what's wrong with using tuple in that case-- e.g. "tuple(5, 10)"?

Static arrays work because you should be able to push existing D code not written specifically for LuaD use. It is for the same reason that void[] parameter types are allowed. wchar and dchar aren't allowed even for functions because the hidden cost is nontrivial.

I have a proposal to address both of these:

There are no user-defined attributes in D (yet).

One obvious solution could be:

import luad.all;
import std.array;

LuaVariableReturn split(in char[] str)
{
    return LuaVariableReturn(split(str));
}

Where LuaVariableReturn could store any input range.

[belm0]

There are no user-defined attributes in D (yet).

Disappointing to hear-- attributes are a basic tool for managing bindings.

The dedicated type solution seems like a reasonable workaround.

[belm0]

I looked at the new documentation and I'm not sure this is generally addressed. In order to implement common Lua API's we need to return a variable number of values of differing types. Does LuaVariableReturn support that?

[JakobOvrum]

Yes, by using std.variant.Algebraic, a custom VariantN instantiation or just LuaObject.

Anyway, I broke some stuff like LuaFunction.opCall, so I am reopening this issue.

[JakobOvrum]

Although the details haven't been settled yet, it looks like user-defined attributes are coming to D.

LuaD can take advantage of this as proposed by @belm0 initially, and probably in many other places too.