[swift-evolution] [Proposal] Variadics as Attribute

Haravikk swift-evolution at haravikk.me
Sat Jul 9 05:03:36 CDT 2016


> On 8 Jul 2016, at 21:18, Kristóf Liliom <kristof.liliom at mattakis.com> wrote:
> 
> I read through this proposal, and I have the feeling that we are trying to solve an issue with Swift from the wrong angle. IMHO Swift has one of the best implementations of variadics which has only one major downfall: passing an array as a variadic argument is not possible. Maybe it would be a better idea to leave method declarations as is and only change the call-site as something like this:
> 
> func someMethod(_ values:Int...) { /* values: 1, 2, 3, 4 */ }
> 
> func someMethod2(_ values:Int...) {
>     someMethod(#unpack(values)) // Or #variadic
> }
> 
> someMethod2(1, 2, 3, 4)
> 
> This would tell the compiler to pass the array's values. Maybe in a more advanced scenario, even this could be supported:
> 
> func someMethod(_ values:Int...) { /* values: -1, -2, 1, 2, 3, 4, -3, -4 */ }
> 
> func someMethod2(_ values:Int...) {
>     someMethod(-1, -2, #unpack(values), -3, -4) // Or #variadic
> }
> 
> someMethod2(1, 2, 3, 4)
> 
> I know this is not a well defined idea, but please give it a thought, could it be a feasible solution to this problem?

These are a possible compromise certainly, but it's not exactly pretty, as I'm not sure it would eliminate the desire to define collection-based methods anyway, as it'll still be neater to just define both so you can do someMethod(values) directly (when it's not ambiguous), in which case this capability only really benefits us when only the variadic option is defined and we have no choice but to use it which feels a little like solving the wrong problem (we'd be working around a developer's unwillingness to define flexible options).

Part of my aim with this proposal is to remove variadic function declarations as being this weird kind of special function type, so we can just use a standard function declaration and enable the part that actually makes them different; the way they're called.

While the issue of ambiguity is a real one, it seems to me that the problem is specific to Any…, or any other type that can represent both a collection and the elements it can contain. Another possible solution could just be a parameter on this proposal's attribute so we can solve the issue as we do now, for example:

	func print(@variadic(only) _ values:[Any]) { print(contentsOf: values) } // Can only be called variadically
	func print(contentsOf:[Any]) { … } // Can only be called with an array

Here we resolve the ambiguity exactly as we do right now; with one variadic-only declaration, and one array-only declaration. However, for cases where the type isn't Any (and thus should be unambiguous) we will only need a single function to handle both cases.

I know that Any… is necessary for print-style methods like the above example, but other than that how common is it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160709/ea075483/attachment.html>


More information about the swift-evolution mailing list