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

[Joe Groff]

> On Feb 2, 2016, at 3:58 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
>> 
>> On Feb 2, 2016, at 4:42 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>>> 
>>> On Feb 2, 2016, at 3:03 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> In current Swift,  this approach does not preserve argument labels :
>>> 
>>> let partial1 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) } // (CGFloat) -> CGPoint
>>> let partial2 = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) } // (CGPoint, CGFloat) -> CGPoint
>>> 
>>> 
>>> must be called partial1(0.5), not partial1(x: 0.5), unless you go to some significant work, as in the following:
>>> 
>>> let partial1: (x: CGFloat) -> CGPoint = {
>>>     projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $0) 
>>> }
>>> 
>>> It's not that this is undoable, it's just ugly and laborious, things that are un-Swifty.  You must decide a priori which arguments will be applied, and manually name those that will not.
>>> 
>>> Compare with, for example, an imaginary version that uses $$ to accomplish the same with less planning and greater win:
>>> 
>>> let partial1 = projectFunctionToCoordinateSystem(function: mySinFunction, p0: p0, p1: p1, x: $$) // (x: CGFloat) -> CGPoint
>>> 
>>> I find it a lot cleaner, less crufty™ and nicer to use than jerry-rigging with a closure.
>> 
>> Closures having unlabeled arguments is a feature, IMO. Propagating labels through the function type system introduces type differences where there don't need to be.
>> 
>> -Joe
> 
> I'm not suggesting they do otherwise. I was saying that using closures for partial application vs scala-style currying has a cost, which makes them less desirable for this (partial) application.

Ultimately, I think we want argument labels to be part of the name, not half-part-of-the-name-half-part-of-the-type like they are today. In the pure-names model, you could plausibly be allowed to name closure variables with compound names:

let partial2(p1:x:) = { projectFunctionToCoordinateSystem(function: mySinFunction, p0: .zero, p1: $0, x: $1) }

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160202/315f3d0d/attachment.html>