RFC for Variable Arity Functions

[zmoshansky]

Ongoing Discussion in Issue #1586.

[ticki]

To me, this is not something that belongs in a strongly typed systems language.

[nixpulvis]

This is something I wouldn't rule out so quickly but it should be done with care. How this effects default arguments, and overloading need to be considered. I'm not sure this RFC without information about the surrounding issues can be accepted.

I really like MLs notion of tuples as the source of arguments to functions in the form foo(...). I'm not sure this is appropriate for Rust, but it's an idea, and syntactically consistent.

[golddranks]

I'm not too fond of the idea because it supports the idea that there is multiple function bodies under one name, which I find confusing. Of course, specialization undermines this too, but I feel it's a slightly different thing: specialization applies for generic traits and functions (not stand-alone functions at the moment, but whatever), and requires there to be the most generic base case. I find that reassuring, because the base-case can be thought to set the precedent of how the semantics of the function should be, and the specializations should follow that, unless clearly and loudly indicated in documentation. But there is no such a precedent-setting base case with these.

Also, there is a lot of missing from the RFC. For example, if take a pointer to function, how do I select which N-ary version I mean? In this case it's clear: let f: fn(i32) -> i32 = varar_func; but in this case it isn't: let f = varar_func; Should type inference infer that too? That isn't discussed at all in the RFC.

Also, if there is going to be variadic generics in the future, there is then functions that are manually overloaded by arity as described here, and functions that are defined generically. That should at least be mentioned and given some thought.

[zmoshansky]

Thanks for the feedback everyone, I appreciate it. I've update my PR with feedback regarding those areas.

Particularly:

• Function Pointers
• Variadic Functions
• Default Arguments
• Overloading
• Multiple Function Bodies use case and Intention (Invariant unified function call syntax #4, Identical Argument Types)

[nikomatsakis]

We discussed this in the @rust-lang/lang meeting. There were many concerns raised with this overall approach. The single biggest concern is that there was a general reluctance to complicate method dispatch more (for users, not necessarily the compiler) by adding another orthogonal kind of overloading. Moreover, while overloading on arity works fine for calls, it doesn't interact well with fully qualified paths to methods (aka UFCS) like T::method or <T as Trait>::method. We would presumably have to augment this syntax somehow (this may have been addressed in the commit pushed ~4 hours back, I haven't had a change to read that yet).

Finally, most people felt like default arguments was generally what was most desired in practice -- and while this can be modeled with overloading based on arity, it's more verbose than supporting default arguments -- and (as mentioned here) raises other complications to be considered. In general we felt like we'd rather see a proposal along those lines (defaulted arguments) than this more general arity-based overloading.

[sgrif]

It would seem very strange to me for the language to introduce variable argument length, but not have general static overloading based on types (I am not advocating adding either). Definitely agree that the generally most desired feature is default values, which is fundamentally different (at a high level, at least).

[zmoshansky]

Alright, Thanks for the consideration. I appreciate the feedback and learning more about why this isn't a desired feature. Shall I close this, or is there more to the RFC process/deliberation?

[nikomatsakis]

@zmoshansky

I appreciate the feedback and learning more about why this isn't a desired feature.

Thanks for your understanding! I'll go ahead and close the issue then.