[swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez]

> On Mar 9, 2017, at 10:43 AM, Ricardo Parada <rparada at mac.com> wrote:
> 
> In other languages I normally have a method with a variable number of arguments and another one taking an array. Then one typically ends up calling the other. 
> 
> If we had implicit splatting I imagine it would reduce such methods to only one. 
> 
> However if implicit splatting were to cause problems I think it would be nice to do it explicitly as follows:
> 
> foo(args as Argument…)

That would depend on Joe Groff’s proposal “Replacing `as` for bridging coercion"
[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts



> 
> 
> On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2th at gmx.de <mailto:2th at gmx.de>> wrote:
>>> 
>>>> These is very unfortunate as a solution for “spreading” a collection or tuple so that It can be applied to function taking a variadic.
>>>> It makes sense on the declaration site but not on the call site. 
>>>> 
>>>> someFunc(@nonVariadic [1])  
>>>> someFunc(@variadic [1]) 
>>>> 
>>>> There is nothing special about variadic/ spreading that would warrant an attribute. 
>>>> 
>>>> I think using attributes is not different than using a keyword like c# uses. 
>>>> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword <http://stackoverflow.com/questions/7580277/why-use-the-params-keyword>
>>>> 
>>>> Do we really want to tag every array/tuple with a @variadic or @nonVariadic tag when packing and unpacking parameters?
>>>> 
>>>> variadic/ spreading (AKA packing / unpacking ) is a well known concept to most languages. 
>>> 
>>> I have the impression there is a misunderstanding about the proposal:
>>> It would not only make the variadics-syntax superflous, but also the whole splatting-magic.
>>> There would only be functions that accept arrays, and you could freely choose to feed them a comma-seperated list instead.
>>> The attribute would be written in the function declaration only — and we could even decide that it isn't needed at all, and simply accept lists wherever an array is expected.
>> 
>> Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we would reintroduce it for Array like constructs. 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered <https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered>
>> 
>> I am in favor in explicit splat behavior but I don’t see it happening anytime soon. Its tagged as low priority.  
>> 
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170309/3674f3e9/attachment.html>