[swift-evolution] [Idea] Passing an Array to Variadic Functions

Vladimir.S svabox at gmail.com
Mon Apr 18 14:00:41 CDT 2016


About print() and similar: this should be (in case we remove variadic 
params) overloaded functions with different number of params.

func print()
func print(v1: Any)
func pring(v1, v2: Any) etc

As for #splat. Should we have such problems in working with params or 
should we introduce one more layer of "collection of params" and methods 
for it, instead of explicit use of array of params?

And do you like implicit tuple splat in method/functions? ;-)

In case the most of us supports variadic params : Should we introduce some 
special marker to mark them in code? I feel that we just need such a way to 
tell that "we are calling this method with variadic params", this will be 
in Swift way.
For example select(: id, name, count) or in some other way.
(or select(* id, name, count) or select(# id, name, count).. hm.. just like 
in "Alternatives considered" in SE-0029 with comment:
foo(*x)    // NOT a serious syntax proposal)

P.S. As currently we did remove C-like for(;;) loops and ++ - don't think 
that this "variadic params" feature that is coming from the same C should 
exists in language. Otherwise I can't feel that Swift team is consistent.


On 18.04.2016 21:14, Daniel Duan via swift-evolution wrote:
> Justin Jia via swift-evolution <swift-evolution at ...> writes:
>
>>
>> Hi!Currently, we can’t call a variadic function with an array of arguments.
>
> IMO, this would be a useful addition. Here are my thoughts on the thread so
> far as an imaginary Q&A.
>
> "Why not remove vararg instead?"
>
> As others have mentioned, this feature enable us to write cleaner code. I
> first learned to appreciate it in C, where some books would introduce it as the
> way to implement printf(). I really prefer not to create an array on unrelated
> items just to print() them in Swift.
>
> "Will it be useful in real life?"
>
> If we keep vararg, then enhancing it with a splat feature will make it far
> more useful than it is today. One of my colleague (hi Scott!) encountered its
> limits just last week: once the varadic argumntes becomes an array, there's no
> way to get them "back" as arguments. This becomes an issue if our function
> needs to forward part of its received arguments recursively to itself. Either
> of the following would be great:
>
> func foo(a: Int...) {
>     if !a.isEmpty() {
>         apply(foo, a.dropFirst()) // imaginary apply function.
>         foo(a: #splat(a.dropFirst())) // imaginary splat, syntax TBD.
>     }
> }
>
>
> Therefore, +1.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


More information about the swift-evolution mailing list