[swift-evolution] [swift-evolution-announce] [Review] SE-0029 Remove implicit tuple splat behavior from function applications

[Joe Groff]

> On Feb 5, 2016, at 3:54 PM, Andrew Bennett <cacoyi at gmail.com> wrote:
> 
> Hi Joe,
> 
> I'm sorry to bring up the "common point of confusion", but I'd like a little more clarification to help me review :). Your example of valid syntax is this:
> 
> func f2<T>(a : T) -> T { ... }
> let x = (1, 2)
> f2(x)
> 
> It gets a little more complicated when generic closures are involved. I am wondering which aspects of this (if any) will still valid:
> 
> func call<T,U>(value: T, apply: T->U) -> U {
>     return apply(value)
> }
> func call2<T,U>(apply: T->U) -> (T -> U) {
>     return { apply($0) }
> }
> func test(a: Int, b: Int, c: Int) -> (Int, Int) {
>     return (a + b, b + c)
> }
> 
> let a = call((1, 2, 3), apply: test)
> let b = call2(test)(1, 2, 3)
> 
> By my interpretation apply uses "pass an entire argument list as a single value", so it would be invalid. However I don't think it has the same syntactic ambiguity that you talked about in your proposal.
> 
> If it is invalid:
> Should the compiler only allow (T->U) to be a function from a single value?
Yeah, AIUI.
> Should a change to closure type signatures be more explicit in the proposal?
I think so. It'd probably be a good idea to at least change the syntax to require parens around the argument list, (T) -> U, to make this more apparent.
> You mention a foo(*x) style solution, this would probably also require T* equivalent. Is this something that you view as inevitable, do you think it will be considered within the Swift4 timeframe?
We're definitely interested in designing a proper solution to this, so that useful generic utilities can still be written. When it lands depends on when we have bandwidth to design and implement it.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/38cc1d1d/attachment.html>