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

[Andrew Bennett]

Thank you very much for your response Joe.

That pretty much clarifies everything I wanted, and I think your points are
good for your proposal to be consistent. However I agree with Brent, this
is a feature that I use often and I am unsure whether you're
underestimating its use.

I think I would be happy with your proposal if:

   - Brackets around generic parens lists differentiates single and
   multiple parameters (as you discussed with me).
   - A temporary function was introduced to provide backwards compatibility
   (in a generic setting), until a more thoroughly thought-out proposal is
   made.

Otherwise, I think that this is a great proposal, but I'm afraid my
evaluation is as follows:

 • What is your evaluation of the proposal?
-1

It's a necessary change, it removes ambiguity and a gotcha that exercises
functionality most users won't directly take advantage of. However, it does
not sufficiently cover the timeline or handling of lost functionality. I
feel like it breaks an entire class of existing clear, concise, and robust
functions. It also hinders and practical exploration of generic function
utilities in Swift.

  • Is the problem being addressed significant enough to warrant a change
to Swift?
Yes

 • Does this proposal fit well with the feel and direction of Swift?
Yes and no, I think it fits well in that it reduces surprises and removes
ambiguity. However I think that it will put a stop to many Swift libraries,
current and future, that use splat to provide function utilities. I feel
like this should be a yes, but perhaps the proposal is incomplete in this
regard.

 • If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
As with Brent, I've used other languages with the functionality being
removed and I've found it extremely useful. The lost functionality can
reduce a lot of boilerplate, in many cases making code much more clear,
concise, and robust. The lost functionality allows the complexity of
generalised functions to abstracted, a user need not know how it works, but
can benefit from the added clarity and utility.

 • How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
An in-depth study.

I've explored what could and could not work after this proposal, in code.
I'm using the functionality this proposal removes in production code. I've
experimented with a non-generic solution to splatting, and the limitations
it creates (in a generic context). I've also extrapolated from how the
removed functionality could be expanded with well designed and thought out
language support, and created a proposal (I hope) to pave the way for that.

On Tue, Feb 9, 2016 at 3:01 AM, Joe Groff <jgroff at apple.com> wrote:

>
> 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/20160209/9ad501df/attachment.html>