[pitch] Variadic Arguments should accept Arrays

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.
c# - Why use the params keyword? - Stack Overflow

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.

+1

-DW

···

On Mar 9, 2017, at 6:42 AM, Ricardo Parada via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 26, 2017, at 10:00 PM, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:

foo(["a", "b", "c"] as String...)

I like this

Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we would reintroduce it for Array like constructs.

I am in favor in explicit splat behavior but I don’t see it happening anytime soon. Its tagged as low priority.

···

On Feb 27, 2017, at 1:20 PM, Tino Heth <2th@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.
c# - Why use the params keyword? - Stack Overflow

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.

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...)

···

On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 27, 2017, at 1:20 PM, Tino Heth <2th@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.
c# - Why use the params keyword? - Stack Overflow

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

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

foo(["a", "b", "c"] as String...)

I like this

+1

I really don't get this:
We have methods like NSLayoutConstraint.activate(_ constraints: [NSLayoutConstraint]), which works with an array, declares its parameter to be array and is called with an array. Quite simple.

On the other hand, we have functions which work with an array, but are declared with Type…, and are called with a comma-separated list of elements — and we should add an option to call this function (which works on array!) with an array that is decorated with a strange cast?
That looks extremely awkward to me.

Can I declare a variable like
var list: String… = "a"
?
Imho it's better to get rid of these odd types completely.

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 Mar 9, 2017, at 10:43 AM, Ricardo Parada <rparada@mac.com> wrote:

On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 27, 2017, at 1:20 PM, Tino Heth <2th@gmx.de <mailto:2th@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.
c# - Why use the params keyword? - Stack Overflow

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

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

I'd find it fantastic if they added

var list: String... = 1, 2,3,4,5

However if they remove Variadic arguments then apple would need to remove
it from their apis. To name a few...

print
NSPredicate(format:)
UIAlertView

Removing variadic arguments would be a breaking change though. They would
either need to remove it quickly or deprecate all the methods that use
variadic arguments. Might take awhile before it is removed completely.

···

On Sat, Mar 11, 2017 at 4:47 AM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

foo(["a", "b", "c"] as String...)

I like this

+1

I really don't get this:
We have methods like NSLayoutConstraint.activate(_ constraints:
[NSLayoutConstraint]), which works with an array, declares its parameter to
be array and is called with an array. Quite simple.

On the other hand, we have functions which work with an array, but are
declared with *Type…*, and are called with a comma-separated list of
elements — and we should add an option to call this function (which works
on array!) with an array that is decorated with a strange cast?
That looks extremely awkward to me.

Can I declare a variable like
var list: String… = "a"
?
Imho it's better to get rid of these odd types completely.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I'd find it fantastic if they added

var list: String... = 1, 2,3,4,5

If this list taught me anything, that it is that there is an incredible diversity what people like or dislike ;-)

But would you really prefer that (wait a moment: String??? ;-) over
var list: [Int] = 1, 2, 3
or boring old
var list = [1, 2, 3]
?

However if they remove Variadic arguments then apple would need to remove it from their apis. To name a few...

print
NSPredicate(format:)
UIAlertView

I have to point out that the proposal never aimed to remove variadic call — it has even been suggested to allow them for any array (or other types that can be constructed from an array literal).