According to this thread <Apple Developer Forums; 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”]
I like the idea. Its syntactic sugar so I am not sure how open the core team would be to adding it.
···
On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:
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
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….)
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
According to this thread <Apple Developer Forums; 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
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….)
@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 <cheyo@masters3d.com> 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
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.
···
On 26 Feb 2017, at 19:17, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:
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.
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….)
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.
···
On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:
Actually mine isn't necessarily a breaking change; while my proposal suggests removing the ellipsis style variadic declaration it's not a hard requirement, as it can also be retained as a shorthand for @variadic [T] and/or be deprecated. This is discussed in alternatives considered, as removing ellipsis is my favoured solution, as I just don't think it's an important syntax to retain, and is easily migrated.
My problem with "splatting" arguments into variadics is that it's even more unique syntax to support it.
···
On 26 Feb 2017, at 18:17, Derrick Ho <wh1pch81n@gmail.com> wrote:
That is an interesting solution. Haravikk's solution was a breaking change so it undoubtedly had resistance.
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
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 <wh1pch81n@gmail.com> 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 <swift-evolution@swift.org <mailto: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 <mailto: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
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 <swift-evolution@swift.org> wrote:
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
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.
This is problematic because of the similarities with the proposed one sided ranges in the new String manifesto. These operations produce slices which are collection.
c[i...]... // first dots one sided range, second the spread operator.
a prefix ... operator would be a little better here but just barely.
...c[i...]
I think a prefix of * or ... would work great for declaring and deconstructing.
func foo(_ a: ...[Int]) {} // declared as array required.
foo(...[1,2,3,4])
foo(...(0,1,2,3))
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.
@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 <cheyo@masters3d.com<mailto:cheyo@masters3d.com>> wrote:
On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution <swift-evolution@swift.org<mailto: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
According to this thread<Apple Developer Forums; 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”]
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<mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/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.
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.
···
On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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.
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!
···
On 12 Mar 2017, at 04:33, Ricardo Parada via swift-evolution <swift-evolution@swift.org> 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.
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.
I am not proposing prefix * or prefix … as I think we should let the community decide but I would be opposed to using attributes or keywords.
···
On Feb 27, 2017, at 9:59 AM, Haravikk <swift-evolution@haravikk.me> wrote:
On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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 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.
···
On 27 Feb 2017, at 19:09, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:
On Feb 27, 2017, at 9:59 AM, Haravikk <swift-evolution@haravikk.me <mailto:swift-evolution@haravikk.me>> wrote:
On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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.