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

[Haravikk via swift-evolution]

> On 12 Mar 2017, at 04:33, Ricardo Parada via swift-evolution 
>  wrote:
> 
> I read Haravikk's proposal a second time. I think I see the advantage of 
> being able to use it with other types besides array. 
> 
> I also found disambiguating with the trailing comma to be intuitive. On the 
> other hand I did not find it so intuitive to use @variadic and @nonVariadic 
> to disambiguate.  I would say just pick the trailing comma. 

As written you'd be able to do both, it's just down to personal preference 
which. However, while the comma works fine for enforcing a variadic call, there 
does still need to be a way to tell Swift you want to call with an array, which 
is what the nonVariadic attribute/compiler directive is for; fortunately this 
is a case that only comes up when the function accepts elements of type Any, so 
there's ambiguity as to whether you're passing an array of elements, or an 
element that happens to be an array.

There are some other features being discussed where it might make sense to have 
an expansion operator, and some have proposed using the trailing ellipsis for 
this, so we could end up with something like:

let bar = myFunc(foo...) // call as an array
let baz = myFunc(foo,) // call variadically

But I'm just not sure if it's worth doing only for the single proposal or not? 
I suppose I could mention it in alternatives though!___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

I read Haravikk's proposal a second time. I think I see the advantage of being 
able to use it with other types besides array. 

I also found disambiguating with the trailing comma to be intuitive. On the 
other hand I did not find it so intuitive to use @variadic and @nonVariadic to 
disambiguate.  I would say just pick the trailing comma. 

Thanks

> On Feb 26, 2017, at 12:25 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> I suggest to take a look at the topics "Variadics as an Attribute" and "array 
> splatting for variadic parameters" and 
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
> 
> This is basically the other way round (arrays would accept variadic 
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with 
> types besides array (set, iterator….)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via 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).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Derrick Ho via 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via 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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 9, 2017, at 10:43 AM, Ricardo Parada  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 
> > wrote:
> 
>> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@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 
 
 
 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 
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 
>  wrote:
> 
> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@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
>>> 
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

> On Feb 26, 2017, at 10:00 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> foo(["a", "b", "c"] as String...) 

I like this
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rudolf Adamkovič via swift-evolution]

That’s correct, thanks for the correction. The rule only applies to parameters 
with argument labels.

But still, we’d lost this guarantee of self-documenting, type-safe 
non-emptiness if arbitrary arrays can be passed to variadic parameters with 
argument labels.

R+

> On 8 Mar 2017, at 23:42, Derrick Ho  wrote:
> 
> Rudolf, I don't believe that is a rule.
> 
> One example includes NSLog()
> 
> In which the first parameter is a format string and the second is a variadic 
> argument. The second one can be omitted.
> On Wed, Mar 8, 2017 at 5:09 PM Rudolf Adamkovič via swift-evolution 
> > wrote:
> Correct me if I’m wrong but a variadic argument is guaranteed to have one or 
> more elements in the array. Isn’t that the case? As an example, consider the 
> following initializer:
> 
> public init(state: State, actions: Action...) {
> // ...
> }
> 
> Here, I can count on actions to be a non-empty array. It’s self-documenting 
> and type-safe. How would this work if arrays are (implicitly or explicitly) 
> convertible to variadic arguments?
> 
> R+
> 
>> On 26 Feb 2017, at 17:26, Derrick Ho via swift-evolution 
>> > wrote:
>> 
> 
>> In swift, a variadic argument can become an array without too much effort.
>> 
>> func foo(_ va: String...) {
>>let a: [String] = va
>> }
>> 
>> However, it seems odd to me that an array can not be converted into a 
>> variadic argument
>> 
>> foo(["a", "b", "c"]) // <-error
>> foo("a", "b", "c") // no error
>> 
>> Other people have wondered about this too. 
>> 
>> 
>> According to this thread  
>> Doug Gregor says it is due to some type ambiguity. with Generics.
>> 
>> If type ambiguity is the issue, Do we have the option to cast it to the 
>> correct type?
>> 
>> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String... 
>> to be a type.
>> 
>> What does the community think? Should we be granted some mechanism to turn 
>> an array into a variadic argument?
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Derrick Ho via swift-evolution]

Rudolf, I don't believe that is a rule.

One example includes NSLog()

In which the first parameter is a format string and the second is a
variadic argument. The second one can be omitted.
On Wed, Mar 8, 2017 at 5:09 PM Rudolf Adamkovič via swift-evolution <
swift-evolution@swift.org> wrote:

> Correct me if I’m wrong but a variadic argument is guaranteed to have one
> or more elements in the array. Isn’t that the case? As an example, consider
> the following initializer:
>
> public init(state: State, actions: Action...) {
> // ...
> }
>
> Here, I can count on actions to be a non-empty array. It’s
> self-documenting and type-safe. How would this work if arrays are
> (implicitly or explicitly) convertible to variadic arguments?
>
> R+
>
> On 26 Feb 2017, at 17:26, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In swift, a variadic argument can become an array without too much effort.
>
> func foo(_ va: String...) {
>let a: [String] = va
> }
>
> However, it seems odd to me that an array can not be converted into a
> variadic argument
>
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
>
> Other people have wondered about this too.
> 
>
> According to this thread
>  Doug Gregor says it
> is due to some type ambiguity. with Generics.
>
> If type ambiguity is the issue, Do we have the option to cast it to the
> correct type?
>
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String...
> to be a type.
>
> What does the community think? Should we be granted some mechanism to turn
> an array into a variadic argument?
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rudolf Adamkovič via swift-evolution]

Correct me if I’m wrong but a variadic argument is guaranteed to have one or 
more elements in the array. Isn’t that the case? As an example, consider the 
following initializer:

public init(state: State, actions: Action...) {
// ...
}

Here, I can count on actions to be a non-empty array. It’s self-documenting and 
type-safe. How would this work if arrays are (implicitly or explicitly) 
convertible to variadic arguments?

R+

> On 26 Feb 2017, at 17:26, Derrick Ho via swift-evolution 
>  wrote:
> 
> In swift, a variadic argument can become an array without too much effort.
> 
> func foo(_ va: String...) {
>let a: [String] = va
> }
> 
> However, it seems odd to me that an array can not be converted into a 
> variadic argument
> 
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
> 
> Other people have wondered about this too. 
> 
> 
> According to this thread  
> Doug Gregor says it is due to some type ambiguity. with Generics.
> 
> If type ambiguity is the issue, Do we have the option to cast it to the 
> correct type?
> 
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String... to 
> be a type.
> 
> What does the community think? Should we be granted some mechanism to turn an 
> array into a variadic argument?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@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 
>> 
>> 
>> 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

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

[Tino Heth via swift-evolution]

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

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

[Haravikk via swift-evolution]

> On 27 Feb 2017, at 19:09, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Feb 27, 2017, at 9:59 AM, Haravikk > > wrote:
>> 
>> 
>>> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution 
>>> > wrote:
>>> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
>>> > wrote:
>>> 
 I suggest to take a look at the topics "Variadics as an Attribute" and 
 "array splatting for variadic parameters" and 
 https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
  
 .
 
 This is basically the other way round (arrays would accept variadic 
 arguments), but it has the same effect — and more:
 You get rid of the odd "…" type, and it's also possible to use this with 
 types besides array (set, iterator….)
>>> I agree with getting rid of the Type... because we could use ... in slicing 
>>> (see String manifesto). Why must it be an attribute and not just "*" ? The 
>>> advantage I see is that this will play great in also deconstructing 
>>> collection like things like Array, Slice and Tuple. This is already 
>>> familiar to python and ruby users. 
>> 
>> Part of the aim is to avoid less easily discovered custom syntax; the point 
>> of the proposal is that there's no need for a special syntax just to support 
>> variadics as attributes already exist, plus they're more descriptive about 
>> what they do and easy to look-up.
> 
> 
> 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]) 

These are only required in the case that a function accepts arguments of type 
Any; since both the array itself, and its contents are valid example of Any. 
This isn't the case if the variadic is on any other type.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
> > wrote:
> 
>> I suggest to take a look at the topics "Variadics as an Attribute" and 
>> "array splatting for variadic parameters" and 
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
>>  
>> .
>> 
>> This is basically the other way round (arrays would accept variadic 
>> arguments), but it has the same effect — and more:
>> You get rid of the odd "…" type, and it's also possible to use this with 
>> types besides array (set, iterator….)
> I agree with getting rid of the Type... because we could use ... in slicing 
> (see String manifesto). Why must it be an attribute and not just "*" ? The 
> advantage I see is that this will play great in also deconstructing 
> collection like things like Array, Slice and Tuple. This is already familiar 
> to python and ruby users. 

Part of the aim is to avoid less easily discovered custom syntax; the point of 
the proposal is that there's no need for a special syntax just to support 
variadics as attributes already exist, plus they're more descriptive about what 
they do and easy to look-up.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> I suggest to take a look at the topics "Variadics as an Attribute" and "array 
> splatting for variadic parameters" and 
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
> 
> This is basically the other way round (arrays would accept variadic 
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with 
> types besides array (set, iterator….)
I agree with getting rid of the Type... because we could use ... in slicing 
(see String manifesto). Why must it be an attribute and not just "*" ? The 
advantage I see is that this will play great in also deconstructing collection 
like things like Array, Slice and Tuple. This is already familiar to python and 
ruby users. 

> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dimitri Racordon via swift-evolution]

> IMHO, it's a more elegant solution to the same problem. I might be worth 
> pursuing it despite the breaking change because it has more chance of being 
> considered than pure syntactic sugar which the core team is not even 
> considering before Swift 4.

Besides, if I understood correctly I think now is the good time to submit 
breaking proposals.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> On 26 Feb 2017, at 19:17, Derrick Ho via swift-evolution 
>  wrote:
> 
> That is an interesting solution.  Haravikk's solution was a breaking change 
> so it undoubtedly had resistance. 

IMHO, it's a more elegant solution to the same problem. I might be worth 
pursuing it despite the breaking change because it has more chance of being 
considered than pure syntactic sugar which the core team is not even 
considering before Swift 4.

> If we were to merely allow Arrays to be cast as type String... then there 
> were be nothing to break.
> 
> String... is technically not a real type though, so when you use it anywhere 
> outside of a functions argument list, it will not compile.
> 
> Maybe we can make a special case?
> 
>> On Sun, Feb 26, 2017 at 12:25 PM Tino Heth <2...@gmx.de> wrote:
>> I suggest to take a look at the topics "Variadics as an Attribute" and 
>> "array splatting for variadic parameters" and 
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
>> 
>> This is basically the other way round (arrays would accept variadic 
>> arguments), but it has the same effect — and more:
>> You get rid of the odd "…" type, and it's also possible to use this with 
>> types besides array (set, iterator….)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dimitri Racordon via swift-evolution]

I was also in favour of using an ellipsis operator to “unsplat” (to borrow the 
term in some other languages) an array into variadic parameters. However, after 
taking a look at Haravikk’s proposal [1] I think I would oppose using ellipsis 
for that purpose.

The main advantage I see is that this proposal enables future extensions to 
other kind of iterable collections (as shown in the “Proposed Extension” 
section). It'd break with “legacy” variadic features and would give Swift a 
more powerful feature to design APIs.

[1] 
https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md


On 27 Feb 2017, at 04:00, Derrick Ho via swift-evolution 
> wrote:

Well, I have found these discussions...

It was marked as a bug and then directed 
to swift 
evolution.

@jose, the prefix operator you mention looks good, but in the past discussions 
they wanted a postfix operator so that it would match the declaration.  I think 
I like the postfix operator.

func foo(_ a: String...) {}

foo(["a", "b", "c"]...) //<- This looks clear.  It is turning the array into a 
variadic argument.

However, that thread was closed because it wasn't "discussed" enough prior 
making the pull request.

therefore, if people want it, they got to cast their vote in here by either 
supporting it or opposing it.

I like my original suggestion since it is more explicit.

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



On Sun, Feb 26, 2017 at 7:59 PM Jose Cheyo Jimenez 
> wrote:
On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution 
> wrote:

In swift, a variadic argument can become an array without too much effort.

func foo(_ va: String...) {
   let a: [String] = va
}

However, it seems odd to me that an array can not be converted into a variadic 
argument

foo(["a", "b", "c"]) // <-error
foo("a", "b", "c") // no error

Other people have wondered about this 
too.

According to this thread 
Doug Gregor says it is due to some type ambiguity. with Generics.

If type ambiguity is the issue, Do we have the option to cast it to the correct 
type?

foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String... to 
be a type.

I think this needs to be done with a spread operator in order to disambiguate.

foo(...["a", "b", "c”]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator

I like the idea. Its syntactic sugar so I am not sure how open the core team 
would be to adding it.


What does the community think? Should we be granted some mechanism to turn an 
array into a variadic argument?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Derrick Ho via swift-evolution]

Well, I have found these discussions...

It was marked as a bug  and then
directed to swift evolution

.

@jose, the prefix operator you mention looks good, but in the past
discussions they wanted a postfix operator so that it would match the
declaration.  I think I like the postfix operator.

func foo(_ a: String...) {}

foo(["a", "b", "c"]...) //<- This looks clear.  It is turning the array
into a variadic argument.

However, that thread was closed because it wasn't "discussed" enough prior
making the pull request.

therefore, if people want it, they got to cast their vote in here by either
supporting it or opposing it.

I like my original suggestion since it is more explicit.

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



On Sun, Feb 26, 2017 at 7:59 PM Jose Cheyo Jimenez 
wrote:

> On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In swift, a variadic argument can become an array without too much effort.
>
> func foo(_ va: String...) {
>let a: [String] = va
> }
>
> However, it seems odd to me that an array can not be converted into a
> variadic argument
>
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
>
> Other people have wondered about this too.
> 
>
> According to this thread
>  Doug Gregor says it
> is due to some type ambiguity. with Generics.
>
> If type ambiguity is the issue, Do we have the option to cast it to the
> correct type?
>
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String...
> to be a type.
>
>
> I think this needs to be done with a spread operator in order to
> disambiguate.
>
> foo(...["a", "b", "c”]
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator
>
> I like the idea. Its syntactic sugar so I am not sure how open the core
> team would be to adding it.
>
>
> What does the community think? Should we be granted some mechanism to turn
> an array into a variadic argument?
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jose Cheyo Jimenez via swift-evolution]

> On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution 
>  wrote:
> 
> In swift, a variadic argument can become an array without too much effort.
> 
> func foo(_ va: String...) {
>let a: [String] = va
> }
> 
> However, it seems odd to me that an array can not be converted into a 
> variadic argument
> 
> foo(["a", "b", "c"]) // <-error
> foo("a", "b", "c") // no error
> 
> Other people have wondered about this too. 
> 
> 
> According to this thread  
> Doug Gregor says it is due to some type ambiguity. with Generics.
> 
> If type ambiguity is the issue, Do we have the option to cast it to the 
> correct type?
> 
> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String... to 
> be a type.

I think this needs to be done with a spread operator in order to disambiguate. 

foo(...["a", "b", "c”] 

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator
 


I like the idea. Its syntactic sugar so I am not sure how open the core team 
would be to adding it. 

> 
> What does the community think? Should we be granted some mechanism to turn an 
> array into a variadic argument?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Derrick Ho via swift-evolution]

That is an interesting solution.  Haravikk's solution was a breaking change
so it undoubtedly had resistance.

If we were to merely allow Arrays to be cast as type String... then there
were be nothing to break.

String... is technically not a real type though, so when you use it
anywhere outside of a functions argument list, it will not compile.

Maybe we can make a special case?

On Sun, Feb 26, 2017 at 12:25 PM Tino Heth <2...@gmx.de> wrote:

> I suggest to take a look at the topics "Variadics as an Attribute" and "array
> splatting for variadic parameters" and
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
> .
>
> This is basically the other way round (arrays would accept variadic
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with
> types besides array (set, iterator….)
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

I suggest to take a look at the topics "Variadics as an Attribute" and "array 
splatting for variadic parameters" and 
https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md
 
.

This is basically the other way round (arrays would accept variadic arguments), 
but it has the same effect — and more:
You get rid of the odd "…" type, and it's also possible to use this with types 
besides array (set, iterator….)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Derrick Ho via swift-evolution]

In swift, a variadic argument can become an array without too much effort.

func foo(_ va: String...) {
   let a: [String] = va
}

However, it seems odd to me that an array can not be converted into a
variadic argument

foo(["a", "b", "c"]) // <-error
foo("a", "b", "c") // no error

Other people have wondered about this too.


According to this thread
 Doug
Gregor says it is due to some type ambiguity. with Generics.

If type ambiguity is the issue, Do we have the option to cast it to the
correct type?

foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String...
to be a type.

What does the community think? Should we be granted some mechanism to turn
an array into a variadic argument?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution