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

[Andrew Bennett]

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?
   - Should a change to closure type signatures be more explicit in the
   proposal?
   - 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?

I don't believe a compiler fixit could resolve this without duplicating call
 and call2 for different arities, that only works if they are in a module
under the user's control.

A more common example can be seen in:
 /swift/stdlib/internal/SwiftExperimental/SwiftExperimental.swift

The function composition operator "(f ∘ g)(1,2,3)".

*Preliminary review:*

In general I'm in favour, it seems like a necessary fix. I can see it being
a potential for confusion in most cases. I think it's unclear how many
flow-on effects there may be, and perhaps the impact is underestimated.

However it would be a shame to lose useful function composition utilities,
I believe it is only potentially confusing for the few people writing those
utilities, not for the many people using them.

Thanks,
Andrew



On Sat, Feb 6, 2016 at 8:31 AM, Joseph Lord via swift-evolution <
swift-evolution at swift.org> wrote:

> +1
>
> While I liked the idea the fact it can't be used to operate on a returned
> tuple directly means that it can't be used in the most interesting ways
> from the functional world (I raised a radar on that rdar://17356912). I
> also understand the danger of the implicit nature.
>
> In most app development I haven't used the feature.
>
> While I think a proper explicit splat operator would be nice it is
> definitely low priority and the specification would need some thought and
> the main use might be teaching functional fundamentals so I'm not sure how
> much real use it would get.
>
> Joseph
>
> On 5 Feb 2016, at 18:12, Joe Groff <jgroff at apple.com> wrote:
>
> Hello Swift community,
>
> The review of “Remove implicit tuple splat behavior from function
> applications” begins now and runs through February 9, 2016. The proposal is
> available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md
>
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at
> the top of the message:
>
> Proposal link:
>
>
> http://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md
>
> Reply text
>
> Other replies
>
>
> *What goes into a review?*
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
>
> Thank you,
>
> -Joe
> Review Manager
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
> _______________________________________________
> 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/20160206/09e7ac29/attachment.html>