<html><head></head><body><div>Is there some way that (Type...) as an argument could become to mean ‘Any Collection of type’? A short hand for generic C : CollectionType where C.Generator.Element == Type.</div><div><br></div><div> // Function accepting any collection of Int</div><div> func sum(numbers: Int...) { numbers.reduce(0, combine: +)</div><div> </div><div> // Accepts all of the following:</div><div> func(5, 6, 7)</div><div> func([5, 6, 7])</div><div> func(1...100)</div><div> func(1...100.lazy.filter{ $0 % 2 == 0 })</div><div><br></div><div>It’s just a shame that generic collections are so handy, but a pain to write, whereas parameters of array just need [Type]. Not sure if this could be grafted on top, but just a thought. Possibly any sequence would be even better.</div><div><br></div><div>(The only situation it would be disabled is for a type of Any)<br><br><div class="acompli_signature">Patrick</div><br></div><br><br><br>
<div class="gmail_quote">On Thu, Apr 21, 2016 at 6:12 AM -0700, "Jeremy Pereira via swift-evolution" <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<pre>
> On 20 Apr 2016, at 15:56, Tino Heth <2th@gmx.de> wrote:
>
>
>> The question is whether the downside to variadic parameters is really enough to justify _removing_ an existing language feature.
>>
>> The burden of justification should be on those people wanting to change the language, not on those wanting to maintain the status quo and “I don’t like it” or “I think it makes code a tiny bit less readable” is not sufficient justification, in my opinion because you already have the option not to use the feature.
> Afaics, this isn't true:
> Increment/decrement operators, currying, tuple splat and even the C-style for loop have already been deprecated, and although I would have preferred to keep some of those constructs, I think it is good how progressive Swift is pushed forward ("would we add this feature now if it wasn't already there?”).
How do these examples show that the burden of justification should not be on those people making the change? I have not claimed that language features should never be removed, only that removal needs some sort of real justification.
I don’t think "would we add this feature now if it wasn't already there?” is sufficient anymore, if it ever was. The global Swift code base is growing day by day and each time you remove a feature, you piss somebody off. If the perception of the Swift community is that we keep taking their toys away, it will impede the growth in Swift’s popularity.
>
> The value of variadic functions is imho less than the possibility to omit "()" in procedure calls, and afair, there have been several posts that illustrate the complications of this feature.
I don’t think “it’s a bit complicated” is necessarily good justification for removing a feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
</pre>
</div>
</blockquote>
</div>
</body></html>