[swift-evolution] [Proposal] Automating Partial Application via Wildcards

[Matthew Johnson]

> On Feb 2, 2016, at 12:59 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Yeah, I'm with Greg—I don't think this saves much over an explicit closure with $N arguments. Another problem with '_' is that it's nonobvious what the boundaries of the closure should be. You can say that it's the enclosing function application, but in the AST, a method invocation is two function applications, so by that rule '_.foo(_)' would mean {{ $0.foo }($0)}, and every operator is a separate function call, so '_ + _ + _' would be '{{ $0 + $1 } + $0}', neither of which is likely to be expected. The { $N } syntax is almost as compact, and is both clearer and more general.

I generally agree that specific syntax for partial application is not necessary.  The {} wrapping the closure is not burdensome enough to justify a special case feature for partial application.

However, I am not a huge fan of the $N placeholder syntax.  It looks noisy and also gets lost in the rest of the expression much more than underscore(s).  `_` leaves visual “whitespace” which makes the “hole” in the expression stand out.  

I know there is concern about overloading the semantics of `_` which is unfortunate as IMO it is the best symbol to serve as a placeholder.  I wonder if there has been confusion about the semantics in practice in languages like Scala where it is used in both ways.  Is there any evidence that this has been a problem?

I would like to see us consider switching to the the approach Dave posted:

> Other systems have used “_”, and, for reordering parameters, “_0”,
> “_1”, ...
> 
> let partial1 = f(arg1: 1, arg2: _) // { f(arg1: 1, arg2: $0) }
> let partial2 = f(arg1: _1, arg2: _0) // { f(arg1: $1, arg2: $0) }


Naked `_` would refer arguments in syntactic order, and could perhaps be limited to “partial application” style closures and single-argument closures.  In other cases `_N` would be used rather than `$N`.

-Matthew

> 
> -Joe
> 
>> On Feb 2, 2016, at 10:41 AM, Greg Titus via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> What about $N?  :-)  
>> 
>> And then you could also put {} around it so that it is more obvious that partial1 is being assigned something that acts like a closure, and then you end up with:
>> 
>> let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) }
>> let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }
>> 
>> instead of:
>>> let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: _) 
>>> let partial2 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: _, x: _) 
>> 
>> I’m -1.
>> 
>> With the way that single expression closures work, and the fact that they are so syntactically light, I don’t think that this proposal would add utility, it would just be one more construct to learn.
>> 
>> 	- Greg
>> 
>>> On Feb 2, 2016, at 10:28 AM, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> What about nothing?
>>> 
>>> let partial1 = f(arg1: 1, arg2:)
>>> Gwendal
>>> 
>>>> Le 2 févr. 2016 à 19:26, Gwendal Roué <gwendal.roue at gmail.com <mailto:gwendal.roue at gmail.com>> a écrit :
>>>> 
>>>> Any operator character would be bad, since the function may accept it, as in `[1,2,3].reduce(1, combine: *)`
>>>> 
>>>> Gwendal
>>>> 
>>>>> Le 2 févr. 2016 à 19:24, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>>> 
>>>>> 
>>>>>> On Feb 2, 2016, at 11:20 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>>>>> 
>>>>>> On Feb 2, 2016, at 10:16 AM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>>>>>> 
>>>>>>>> One superficial comment on this: the use of _ here is a bad idea.  _ already means something in expressions - “discard”, and a closely related thing in declarations - “ignore”.  
>>>>>>>> 
>>>>>>>> Adding a third very different thing (placeholder to be filled in later) seems like a really confusing thing to do.
>>>>>>>> 
>>>>>>>> -Chris
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> #?
>>>>>> 
>>>>>> # means “macro like” or “compiler synthesized”.
>>>>>> 
>>>>>> -Chris
>>>>>> 
>>>>> 
>>>>> * would be bad, right? And naked ?-marks?
>>>>> 
>>>>> -- E
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160202/1e4b88e4/attachment.html>