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

[Joe Groff]

> On Feb 2, 2016, at 3:03 PM, Erica Sadun via swift-evolution <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

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