let myArray = Array([1, 2, 3, 4]) Is that an array with a single element that is an array, or is that a flat array with 4 numbers in it? There is no ambiguity here today - it’s an array with an array inside of it. How do you resolve this sort of situation after removing variadics?
For the record, I’m very -1 for removing variadic but very +1 for a way to inject the contents of an array into a variadic function when calling it. l8r Sean > On Apr 19, 2016, at 3:06 PM, Haravikk via swift-evolution > <[email protected]> wrote: > > >> On 19 Apr 2016, at 20:25, Justin Jia <[email protected]> wrote: >> >> Cons of removing variadic functions: >> 1. More verbose syntax. >> 2. Break old code. > > The verbosity is only two characters (square brackets), and it needn’t break > old code: > > Before: func myFunc(values:Foo…) > After: func myFunc(values:[Foo]) > > Before: myFunc(foo, bar, baz) > After: myFunc([foo, bar, baz]) > > Currently variadic functions just produce an array of arguments anyway, so > simply translating call-sites to pass in an array guarantees compatibility. > >> On Apr 19, 2016, at 10:54 AM, Haravikk <[email protected]> wrote: >> >>> >>>> On 19 Apr 2016, at 17:51, Vladimir.S <[email protected]> wrote: >>>> >>>> I.e. the question is *if we want/need to be able to pass array to existed >>>> variadic function*. Not about removing the variadic feature("removing" is >>>> offtop for this poposal, as I understand) >>> >>> I’d say it’s on-topic, as removing variadic functions would eliminate the >>> problem entirely, so if it is considered a better alternative then there >>> would be no need to have an additional means of calling them with an array >>> of arguments. >>> >>> Personally the way I see it comes down to variadic functions is this: >>> >>> Pros: >>> • Slightly cleaner syntax at call-site. >>> • Possibly optimisations unavailable to Array passing? >>> >>> Cons: >>> • Doesn’t do anything that passing an array directly can’t. >>> • Passing an array is actually slightly more flexible (can dynamically >>> pass more or less arguments as required at the call site). >>> • Less explicit type at call site; gives the appearance of passing >>> instance(s) of Foo, rather than one instance of [Foo], can lead to >>> ambiguity with overloaded functions. >>> • Extra syntax to support (enabling array passing would be more code >>> required to support this feature) >>> >>> I’d also argue that variadic functions increase the learning curve, as the >>> first time you’re presented with one it isn’t necessarily clear what it >>> does unless you’ve encountered them before. Like I say it can be ambiguous >>> at the call-site in particular, as it doesn’t show that an array of [Foo] >>> is being passed as opposed to N instances of Foo (however many are in the >>> call). >>> >>> While I’ve used them in the past, I’ve never really felt that they simplify >>> anything enough to justify them, as it’s just two square brackets extra to >>> pass an array; this is extra noise sure, but clarifies what is actually >>> happening. >>> >>> So if variadic functions don’t have any other advantages, then it’s really >>> just a very minor piece of syntactic sugar that can lead to more confusion, >>> less explicit types in function calls, an extra piece of syntax to parse >>> and handle and possibly other features required to support it better (like >>> the one being inquired about). The only other argument I can think of for >>> them is that many other languages have them, but that’s not important to me >>> vs cutting out cruft. >>> >>> >>> Short version; removing variadic functions would solve the problem of >>> defining overloads for both variadic and array types by only ever requiring >>> the latter. >>> >>> P.S- I’d also like to note that where possible people should be accepting >>> Sequences or Collections in their methods anyway rather than arrays >>> specifically, as it’s more flexible that way ;) > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
