[swift-evolution] named parameters

Erica Sadun erica at ericasadun.com
Fri Jan 22 18:31:44 CST 2016

> On Jan 22, 2016, at 5:27 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> On Jan 22, 2016, at 3:10 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> Additionally, there is a hidden(?) feature in Swift that's imho quite cool:
>>>>> The ability to call a function with a tuple containing the arguments
>>>>> let args = (4.0, exponent: 4.0)
>>>>> printPowWithBase(args)
>>>>> In this case, you end up with a first parameter without any indication of its role.
>>>> This feature is likely to get redesigned soon. (It has other problems.)
>>> Can you elaborate? I did not encounter many usecases yet, but I think it could be handy to configure a bunch of similar objects — and if it would be possible to capture the parameter tuple inside the called function, this could be forwarded to a function with the same signature easily… (especially, but not only the implementation of super)
>> In some contexts it's hard to distinguish between "the first parameter" and "the tuple of all parameters", and we have some weird inconsistencies where "foo(x)" and "foo((x))" do the same thing sometimes and different things other times.
> Here’s a simple example to show the ambiguity:
> func foo(a : Any…) {}
> let x = (1,2,3)
> foo(x)   // 1 parameter or 3?
>> There's more complexity here but I don't have it paged in; it's not so relevant to this discussion
> Incidentally, IMO the likely solution is for this to just make this explicit somehow.  * isn’t really right right sigil for this, but you could imagine something like this:
> printPowWithBase(*args)
> Where the * (or whatever symbol actually makes sense) is a “flatten” or “expand inline” operation for the tuple argument.  This makes it unambiguous whether splatting is happening or not.
> func foo(a : Any…) {}
> let x = (1,2,3)
> foo(x)   // 1 parameter
> foo(*x)  // 3 parameters
> Alternatively, the argument could be made that we should just remove this splatting behavior.  I haven’t heard of any super-compelling use-cases for it.  Adding a sigil for this operation would expose the complexity that the behavior underlines.

Use case:

Zipping streams of arguments into tuples and then applying them through a function, and for the sake of argument, there's a big scary monster of necessity preventing you from consuming them at the same time using f($0, $1, $2, etc), so the lazy zipped tuple stream occurs at a different time/place as the consumption, which is not expecting a tuple input but n separate arguments.

-- E

> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160122/df1041c2/attachment.html>

More information about the swift-evolution mailing list