Re: [swift-evolution] array splatting for variadic parameters

[Tino Heth via swift-evolution]

> What about calling a framework variadic function that I could not re-declare?
> like print
That’s a good question — in „regular“ frameworks, variadic functions as we have 
them now wouldn’t exist anymore, but C is a different story…
My expectation (without deep knowledge of the compatibility-layer) is that it 
isn't hard to solve this; after all, it’s basically just a small change in 
syntax (although afair, T… is a special case in the type system).

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

Re: [swift-evolution] array splatting for variadic parameters

[Cao, Jiannan via swift-evolution]

What about calling a framework variadic function that I could not re-declare?
like print

> 在 2017年12月2日，上午1:26，Tino Heth <2...@gmx.de > 写道：
> 
> There has been a solution to the same problem that’s imho much nicer, because 
> instead of adding fundamental new syntax, it removes a piece of C-legacy:
> 
> Basically,instead of
> func f(args: Int…)
> you would just declare
> func f(args: @variadic [Int])
> or even
> func f(args: [Int])
> and interpret any argument that’s a comma-separated list as an array — or, 
> and that’s imho another useful aspect, something else that can be expressed 
> with an array literal
> func f(args: Set)
> 
> So you would not only make the language surface smaller, but also add new 
> abilities that basically come for free (they would still have to be 
> implemented, though ;-)
> 
>> Am 30.11.2017 um 22:13 schrieb Cao, Jiannan via swift-evolution 
>> >:
>> 
>> What happened with this proposal? This looks easy to implement.
>> 
>> func sumOf(numbers: Int...) -> Int {
>>   ...
>>   }
>> typealias Function = [Int] -> Int
>> let sumOfArray = unsafeBitCast(sumOf, Function.self)
>> sumOfArray([1, 2, 3])
>> 
>>> Hello everyone.
>>> 
>>> I understand that topic has already been discussed in the past, but I 
>>> failed to get any information on its current state of affairs.
>>> 
>>> I guess the subject of this mail is explicit, but to make sure I’m clear, 
>>> here's a small snippet that illustrates the problem:
>>> 
>>> func f(args: Int…) {
>>>   // Some implementation ...
>>> }
>>> // Now it's impossible to call f without explicitly naming its parameters.
>>> 
>>> For many use-cases, this problem can be solved by overloading f so that it 
>>> explicitly accepts an array.
>>> 
>>> func f(_ args: [Int]) {
>>>   // Some implementation ...
>>> }
>>> 
>>> func f(_ args: Int…) {
>>>   f(args)
>>> }
>>> 
>>> Some people also advocate (myself generally included) that one should 
>>> prefer the signature explicitly marking args as an array, as the syntactic 
>>> overhead of wrapping the arguments with “[]” when calling f is arguably 
>>> bearable. However, in some other situations, this approach might not be 
>>> applicable. For instance, one may simply not be able to modify the original 
>>> function. Another use-case may be a function that should forward its own 
>>> variadic parameters.
>>> 
>>> In a variety of other languages, there exists a way to do this. For 
>>> instance, Python can “unpack” (or splat) a list into function arguments by 
>>> prefixing it with *:
>>> 
>>> def f(*args):
>>>   # Some implementation …
>>> 
>>> f(*[1, 2, 3]) # == f(1, 2, 3)
>>> 
>>> I was wondering if such feature could be supported by Swift, and if not, 
>>> why.
>>> 
>>> Syntactically, I like the use of “…”, which would mirror function 
>>> signatures:
>>> 
>>> f(…[1, 2, 3]) // == f(1, 2, 3)
>>> 
>>> Thanks.
>>> 
>>> --
>>> Dimitri Racordon
>> 
>> ___
>> 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] array splatting for variadic parameters

[Tino Heth via swift-evolution]

There has been a solution to the same problem that’s imho much nicer, because 
instead of adding fundamental new syntax, it removes a piece of C-legacy:

Basically,instead of
func f(args: Int…)
you would just declare
func f(args: @variadic [Int])
or even
func f(args: [Int])
and interpret any argument that’s a comma-separated list as an array — or, and 
that’s imho another useful aspect, something else that can be expressed with an 
array literal
func f(args: Set)

So you would not only make the language surface smaller, but also add new 
abilities that basically come for free (they would still have to be 
implemented, though ;-)

> Am 30.11.2017 um 22:13 schrieb Cao, Jiannan via swift-evolution 
> :
> 
> What happened with this proposal? This looks easy to implement.
> 
> func sumOf(numbers: Int...) -> Int {
>   ...
>   }
> typealias Function = [Int] -> Int
> let sumOfArray = unsafeBitCast(sumOf, Function.self)
> sumOfArray([1, 2, 3])
> 
>> Hello everyone.
>> 
>> I understand that topic has already been discussed in the past, but I failed 
>> to get any information on its current state of affairs.
>> 
>> I guess the subject of this mail is explicit, but to make sure I’m clear, 
>> here's a small snippet that illustrates the problem:
>> 
>> func f(args: Int…) {
>>   // Some implementation ...
>> }
>> // Now it's impossible to call f without explicitly naming its parameters.
>> 
>> For many use-cases, this problem can be solved by overloading f so that it 
>> explicitly accepts an array.
>> 
>> func f(_ args: [Int]) {
>>   // Some implementation ...
>> }
>> 
>> func f(_ args: Int…) {
>>   f(args)
>> }
>> 
>> Some people also advocate (myself generally included) that one should prefer 
>> the signature explicitly marking args as an array, as the syntactic overhead 
>> of wrapping the arguments with “[]” when calling f is arguably bearable. 
>> However, in some other situations, this approach might not be applicable. 
>> For instance, one may simply not be able to modify the original function. 
>> Another use-case may be a function that should forward its own variadic 
>> parameters.
>> 
>> In a variety of other languages, there exists a way to do this. For 
>> instance, Python can “unpack” (or splat) a list into function arguments by 
>> prefixing it with *:
>> 
>> def f(*args):
>>   # Some implementation …
>> 
>> f(*[1, 2, 3]) # == f(1, 2, 3)
>> 
>> I was wondering if such feature could be supported by Swift, and if not, why.
>> 
>> Syntactically, I like the use of “…”, which would mirror function signatures:
>> 
>> f(…[1, 2, 3]) // == f(1, 2, 3)
>> 
>> Thanks.
>> 
>> --
>> Dimitri Racordon
> 
> ___
> 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] array splatting for variadic parameters

[Cao, Jiannan via swift-evolution]

What happened with this proposal? This looks easy to implement.

func sumOf(numbers: Int...) -> Int {
  ...
  }
typealias Function = [Int] -> Int
let sumOfArray = unsafeBitCast(sumOf, Function.self)
sumOfArray([1, 2, 3])

> Hello everyone.
> 
> I understand that topic has already been discussed in the past, but I failed 
> to get any information on its current state of affairs.
> 
> I guess the subject of this mail is explicit, but to make sure I’m clear, 
> here's a small snippet that illustrates the problem:
> 
> func f(args: Int…) {
>   // Some implementation ...
> }
> // Now it's impossible to call f without explicitly naming its parameters.
> 
> For many use-cases, this problem can be solved by overloading f so that it 
> explicitly accepts an array.
> 
> func f(_ args: [Int]) {
>   // Some implementation ...
> }
> 
> func f(_ args: Int…) {
>   f(args)
> }
> 
> Some people also advocate (myself generally included) that one should prefer 
> the signature explicitly marking args as an array, as the syntactic overhead 
> of wrapping the arguments with “[]” when calling f is arguably bearable. 
> However, in some other situations, this approach might not be applicable. For 
> instance, one may simply not be able to modify the original function. Another 
> use-case may be a function that should forward its own variadic parameters.
> 
> In a variety of other languages, there exists a way to do this. For instance, 
> Python can “unpack” (or splat) a list into function arguments by prefixing it 
> with *:
> 
> def f(*args):
>   # Some implementation …
> 
> f(*[1, 2, 3]) # == f(1, 2, 3)
> 
> I was wondering if such feature could be supported by Swift, and if not, why.
> 
> Syntactically, I like the use of “…”, which would mirror function signatures:
> 
> f(…[1, 2, 3]) // == f(1, 2, 3)
> 
> Thanks.
> 
> --
> Dimitri Racordon

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

Re: [swift-evolution] array splatting for variadic parameters

[Tino Heth via swift-evolution]

> I didn't get an especially positive response to the proposal at the time, but 
> it is still very much my preferred solution.


I'm convinced that the timing had a very huge impact on the reaction:
It was a very busy period, and I had a strong impression that people just 
wanted to limit the workload for the next milestone.

Imho "…"-variadics are a C-legacy that is a much worse fit for Swift than 
things that have been abandoned during times with higher motivation for such 
changes (I'm thinking of the for-loop and the increment/decrement operators).

For me, the change not only removes a strange syntax and type oddity, making 
Swift easier to understand — it also makes the language more powerful without 
additional cost.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] array splatting for variadic parameters

[Dimitri Racordon via swift-evolution]

> "Splatting" as the OP suggests is a simpler solution, but leaves variadics 
> limited to a unique syntax with no control over type;


I also your prefer the proposal than my initial suggestion.

> I could of course be biased, but then I've never really supported variadics 
> as a feature in the first place 


To be perfectly honest, I’m not the biggest zealot of variadics neither =D

However, I spend most of my time writing libraries for people unfamiliar with 
programming, or even computer science in general. As a result, I often provide 
them with "domain specific languages” embedded in some host language. Swift 
fits that job extremely well, thanks to many of its features; variadics are one 
of them.

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

Re: [swift-evolution] array splatting for variadic parameters

[Haravikk via swift-evolution]

> On 14 Feb 2017, at 20:43, Anton Zhilin via swift-evolution 
>  wrote:
> 
> 2017-02-14 18:32 GMT+03:00 Dimitri Racordon via swift-evolution 
> >:
> 
> 
> 
> The proposal is indeed really interesting.
> I would love to see if it could get a second round of discussion.
> 
> However, I failed to understand the syntax of the proposed extension. Where 
> would be defined the label and parameter names? Is this just a typo?
> 
> func someFunc 
> 
> “Obviously”, the Collection variant should look like:
> 
> func someFunc(_ values: 
> @variadic C) { … }
> And the others are analagous.
> 

Thanks for the correction, not entirely sure how that mistake made it into the 
proposal!

I didn't get an especially positive response to the proposal at the time, but 
it is still very much my preferred solution.


"Splatting" as the OP suggests is a simpler solution, but leaves variadics 
limited to a unique syntax with no control over type; I'm also not keen on 
re-using ellipsis as an operator for it, since it's also used for handling 
ranges, though that's not a major overlap. But still, part of why I made my 
proposal is that splatting feels more like a workaround to a problem of there 
not being a proper array/sequence/etc. signature for the function.

I could of course be biased, but then I've never really supported variadics as 
a feature in the first place ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] array splatting for variadic parameters

[Anton Zhilin via swift-evolution]

2017-02-14 18:32 GMT+03:00 Dimitri Racordon via swift-evolution <
swift-evolution@swift.org>:

The proposal is indeed really interesting.
> I would love to see if it could get a second round of discussion.
>
> However, I failed to understand the syntax of the proposed extension.
> Where would be defined the label and parameter names? Is this just a typo?
>
> func someFunc
> “Obviously”, the Collection variant should look like:

func someFunc(_ values:
@variadic C) { … }

And the others are analagous.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] array splatting for variadic parameters

[Dimitri Racordon via swift-evolution]

The proposal is indeed really interesting.
I would love to see if it could get a second round of discussion.

However, I failed to understand the syntax of the proposed extension. Where 
would be defined the label and parameter names? Is this just a typo?


func someFuncmailto:2...@gmx.de>> wrote:


func f(_ args: [Int]) {
  // Some implementation ...
}

func f(_ args: Int…) {
  f(args)
}

Some people also advocate (myself generally included) that one should prefer 
the signature explicitly marking args as an array, as the syntactic overhead of 
wrapping the arguments with “[]” when calling f is arguably bearable. However, 
in some other situations, this approach might not be applicable. For instance, 
one may simply not be able to modify the original function. Another use-case 
may be a function that should forward its own variadic parameters.

There has been a proposal that would not only solve this issue, but also add a 
lot flexibility while simplifying the language at the same time:
https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md

Imho it's one of the best ideas I have seen on evolution, and definitely the 
most valuable segregation of C legacy.
Sadly, it was discussed in a very busy timeframe, and I think it really didn't 
receive the attention it deserves…

I would have asked Haravikk wether he would like to start a second try anyways, 
and as this topic is directly related, it's a good motivation to do so.

The basic idea of the proposal is to get rid of "…"-magic and declare variadic 
parameters with their natural type (Array — but one aspect of this idea is 
that it can be extended easily to work with sets and other types that can be 
expressed with an array literal).

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