> On Mar 9, 2017, at 10:43 AM, Ricardo Parada <[email protected]> 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 > <[email protected] <mailto:[email protected]>> wrote: > >> >>> On Feb 27, 2017, at 1:20 PM, Tino Heth <[email protected] <mailto:[email protected]>> >>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
