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

[Erica Sadun]

> On Feb 2, 2016, at 4:42 PM, Joe Groff <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.

Regardless, I want to thank everyone who participated in this discussion and gave feedback both positive and negative.

Appreciatively, -- Erica
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160202/a778b87f/attachment.html>