Heh.. actually there IS ambiguity today because that uses the SequenceType initializer and not the ArrayLiteralConvertible initializer.. so… hmm. :P
Okay so maybe that was a terrible example. Still -1 for removing variadic. :P l8r Sean > On Apr 19, 2016, at 3:21 PM, Sean Heber <[email protected]> wrote: > > 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
