if you did some trickery with existential type aliases to name a specific function's type, you could probably do this with actual functions or even closures.
1 Like
This feature is called overloading, not variadics. Variadics are a way to write functions that take any number of inputs, while in this case you would have to write an impl for each number and at some point you'll have to stop (which is what many projects already do).
9 Likes
true, although if we ever get variadic tuples this will become a viable option.
and technically speaking ISO C only mandates that compilers are able to handle functions (including variadic functions) with up to 127 arguments, which isn't entirely unreasonable to brute-force.
I'm not sure I understand for what would this be a viable option. If we get variadic tuples the we already get variadics, no?
Even with a limit at 128, doing this library wise is going to be too slow for practical uses, see for example diesel's 128-column-table.
variadic tuples are not necessarily the same as true variadic functions. rust actually already supports calling variadic functions, but they must be defined in another language like C.
Even without nightly features you can somewhat make variadics
fn variadic(args: Vec<&str>) {
// …
}
and call it like this
variadic(vec!["hi", "hello"])
Given that Fn traits use tuples to represent arguments, that really seems like the same thing.
What support there is for variadics, exists only for cffi compatibility.
well, variadic function pointers are kinda neat, i suppose.
I'd expect it to look like this (without allocation):
fn variadic<const N: usize>(args: [&str; N])
But true variadics could also handle different types:
fn variadic(args: ...(impl ToString))
2 Likes
There is room for both kinds of variadics. D, for example, has both:
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.