Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Douglas Gregor via swift-evolution]

> On Oct 5, 2016, at 8:15 AM, Jon Akhtar via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I agree this seems like a pretty serious oversight. This is very un-swifty. 
> Currying at one time was touted as a language feature, now it is more of an 
> afterthought.

I see it as a feature that has mostly been removed in Swift 3: SE-0002 
<https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md>
 eliminating the syntax that defined curried functions, and SE-0042 
<https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
 eliminates the production of curried functions when referring to an instance 
member.  I think that’s because, as a language feature, currying wasn’t really 
carrying it’s conceptual weight: it wasn’t being used *that* often in practice, 
but—unless you’re already familiar with currying from another language—it’s a 
fairly complicated notion to understand, and Swift didn’t ever have a complete 
implementation of currying.

- Doug

> 
> -Jon
> 
> From: <swift-evolution-boun...@swift.org 
> <mailto:swift-evolution-boun...@swift.org>> on behalf of Erica Sadun via 
> swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
> Reply-To: Erica Sadun <er...@ericasadun.com <mailto:er...@ericasadun.com>>
> Date: Tuesday, October 4, 2016 at 09:21
> To: swift-evolution <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>>
> Subject: [swift-evolution] SE-0111 and Curried argument labels: Unintended 
> Consequences
> 
> SE-0111 established that Swift's type system would not allow function 
> argument labels to be expressed as part of a function type. As I've been 
> working with curried functions, I'm discovering an unintended consequence of 
> this proposal in that it strips curried functions of their external labels 
> and the resulting calls of their readability.
> 
> ```
> public func projected(
> function f: @escaping (CGFloat) -> CGFloat) ->
> (_ p0: CGPoint, _ p1: CGPoint) -> 
> (_ percent: CGFloat) -> CGPoint
> {
> ```
> 
> Calling the first level of currying still reads acceptably:
> 
> ```
> let projectedFunction = projected(function: fToApply)
> ```
> 
> But after that, the enforced label-less arguments mean all further semantics 
> have to stay within the name of the assigned partially applied function 
> symbol and all arguments must be supplied without meaning, which is not in 
> the spirit of API guidelines or under the umbrella of Swiftiness:
> 
> ```
> let fixedFunction = projectedFunction(p0, p1)
> let value = fixedFunction(0.2)
> ```
> 
> There's no way to give either the line segment start and end points or the 
> percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
> provide any support for documenting the roles of each curried return type.
> 
> Could this be addressed specifically for currying or has the boat sailed 
> forever on this topic?
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Jon Akhtar via swift-evolution]

I agree this seems like a pretty serious oversight. This is very un-swifty. 
Currying at one time was touted as a language feature, now it is more of an 
afterthought.

-Jon

From: 
<swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> 
on behalf of Erica Sadun via swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Reply-To: Erica Sadun <er...@ericasadun.com<mailto:er...@ericasadun.com>>
Date: Tuesday, October 4, 2016 at 09:21
To: swift-evolution 
<swift-evolution@swift.org<mailto:swift-evolution@swift.org>>
Subject: [swift-evolution] SE-0111 and Curried argument labels: Unintended 
Consequences

SE-0111 established that Swift's type system would not allow function argument 
labels to be expressed as part of a function type. As I've been working with 
curried functions, I'm discovering an unintended consequence of this proposal 
in that it strips curried functions of their external labels and the resulting 
calls of their readability.

```
public func projected(
function f: @escaping (CGFloat) -> CGFloat) ->
(_ p0: CGPoint, _ p1: CGPoint) ->
(_ percent: CGFloat) -> CGPoint
{
```

Calling the first level of currying still reads acceptably:

```
let projectedFunction = projected(function: fToApply)
```

But after that, the enforced label-less arguments mean all further semantics 
have to stay within the name of the assigned partially applied function symbol 
and all arguments must be supplied without meaning, which is not in the spirit 
of API guidelines or under the umbrella of Swiftiness:

```
let fixedFunction = projectedFunction(p0, p1)
let value = fixedFunction(0.2)
```

There's no way to give either the line segment start and end points or the 
percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
provide any support for documenting the roles of each curried return type.

Could this be addressed specifically for currying or has the boat sailed 
forever on this topic?

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Erica Sadun via swift-evolution]

Thank you for that!

-- E

> On Oct 4, 2016, at 4:58 PM, Goffredo Marocchi  wrote:
> 
> Here is the message I was talking about: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html
>  
> 
> 
> Message quoted here for your convenience:
> Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
> 
> Shortly after SE-0111 was accepted last week, several people newly noticed 
> the proposal and started a discussion about how it appears to be a regression 
> for closure parameters (e.g. callbacks) that could formerly carry labels, but 
> are now not allowed to.  These folks observed that it would be more 
> expressive (and consistent with the rest of Swift) to allow parameter labels 
> in function types, because the invocation site of a closure “should" be 
> required to provide those labels.  The core team has been following the 
> discussion, agrees that this is a concern, and wants to update the community 
> with a path forward.
> 
> The reality of the situation is that the current implementation of parameter 
> labels in function types is inherently broken.  Specifically, as one example, 
> there is an implicit conversion from "(a: Int) -> Int” to “(Int) -> Int”.  
> However, there is also an implicit conversion from "(Int) -> Int” to “(b : 
> Int) -> Int”.  This means that the compiler currently allows converting from 
> “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t make sense, introduces 
> surprising behavior, introduces complexity into the compiler implementation, 
> and is generally a problem.  We do have one specific hack to prevent 
> conversion of (e.g.) “(a : Int, b : Int) -> Void” to “(b : Int, a : Int) -> 
> Void”, but this only triggers in specific cases.  There are other more 
> complex cases as well, e.g. when using generics "T<(a : Int)->Int>” cannot be 
> considered compatible with "T<(b : Int)->Int>”.
> 
> These problems are what initially motivated SE-0111.  However, given the 
> feedback, the core team went back to the drawing board to determine whether: 
> a) SE-0111 by itself is the right long term answer, b) whether there were 
> alternate models that could solve the same problems in a different way, or c) 
> whether SE-0111 was the right first step to "ultimate glory" in the field of 
> closure parameter labels.  After a long discussion, and many alternatives 
> considered, the core team believes in c), that SE-0111 (with a minor 
> modification) is the right step for Swift 3, because it paves the way for the 
> right model over the long term.
> 
> 8<
> 
> The specific revision requested by the core team to SE-0111 is that all 
> “cosmetic” labels should be required to include an API name of _.  For 
> example, this would not be allowed:
> 
>var op : (lhs : Int, rhs : Int) -> Int
> 
> instead, it should be spelled as:
> 
>var op : (_ lhs : Int, _ rhs : Int) -> Int
> 
> With this change, we believe that we have paved the way for a purely additive 
> proposal (and thus, post-Swift 3) that will restore the expressive capability 
> of closures with parameter labels.  
> 
> 8<
> 
> Here is a sketch of how that would work, in two steps:
> 
> 
> First, we extend declaration names for variables, properties, and parameters 
> to allow *parameter names* as part of their declaration name.  For example:
> 
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
> 
> This will restore the ability to express the idea of a closure parameter that 
> carries labels as part of its declaration, without requiring parameter labels 
> to be part of the type system (allowing, e.g. the operator + to be passed 
> into something that requires parameter labels).
> 
> 
> Second, extend the rules for function types to allow parameter API labels *if 
> and only if* they are used as the type of a declaration that allows parameter 
> labels, and interpret them as a sugar form for providing those labels on the 
> underlying declaration.  This means that the example above could be spelled 
> as:
> 
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
> 
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Goffredo Marocchi via swift-evolution]

Here is the message I was talking about:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html

Message quoted here for your convenience:

> *Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>  
> 
>
> Shortly after SE-0111 was accepted last week, several people newly noticed 
> the proposal and started a discussion about how it appears to be a regression 
> for closure parameters (e.g. callbacks) that could formerly carry labels, but 
> are now not allowed to.  These folks observed that it would be more 
> expressive (and consistent with the rest of Swift) to allow parameter labels 
> in function types, because the invocation site of a closure “should" be 
> required to provide those labels.  The core team has been following the 
> discussion, agrees that this is a concern, and wants to update the community 
> with a path forward.
>
> The reality of the situation is that the current implementation of parameter 
> labels in function types is inherently broken.  Specifically, as one example, 
> there is an implicit conversion from "(a: Int) -> Int” to “(Int) -> Int”.  
> However, there is also an implicit conversion from "(Int) -> Int” to “(b : 
> Int) -> Int”.  This means that the compiler currently allows converting from 
> “(a: Int) -> Int” to “(b: Int) -> Int”, which doesn’t make sense, introduces 
> surprising behavior, introduces complexity into the compiler implementation, 
> and is generally a problem.  We do have one specific hack to prevent 
> conversion of (e.g.) “(a : Int, b : Int) -> Void” to “(b : Int, a : Int) -> 
> Void”, but this only triggers in specific cases.  There are other more 
> complex cases as well, e.g. when using generics "T<(a : Int)->Int>” cannot be 
> considered compatible with "T<(b : Int)->Int>”.
>
> These problems are what initially motivated SE-0111.  However, given the 
> feedback, the core team went back to the drawing board to determine whether: 
> a) SE-0111 by itself is the right long term answer, b) whether there were 
> alternate models that could solve the same problems in a different way, or c) 
> whether SE-0111 was the right first step to "ultimate glory" in the field of 
> closure parameter labels.  After a long discussion, and many alternatives 
> considered, the core team believes in c), that SE-0111 (with a minor 
> modification) is the right step for Swift 3, because it paves the way for the 
> right model over the long term.
>
> 8<
>
> The specific revision requested by the core team to SE-0111 is that all 
> “cosmetic” labels should be required to include an API name of _.  For 
> example, this would not be allowed:
>
>var op : (lhs : Int, rhs : Int) -> Int
>
> instead, it should be spelled as:
>
>var op : (_ lhs : Int, _ rhs : Int) -> Int
>
> With this change, we believe that we have paved the way for a purely additive 
> proposal (and thus, post-Swift 3) that will restore the expressive capability 
> of closures with parameter labels.
>
> 8<
>
> Here is a sketch of how that would work, in two steps:
>
>
> First, we extend declaration names for variables, properties, and parameters 
> to allow *parameter names* as part of their declaration name.  For example:
>
>var op(lhs:,rhs:) : (Int, Int) -> Int// variable or property.
>x = op(lhs: 1, rhs: 2)   // use of the variable or property.
>
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse  op(lhs:,rhs:) : (Int, Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // use of the parameter
>}
>foo(opToUse: +) // call of the function
>
> This will restore the ability to express the idea of a closure parameter that 
> carries labels as part of its declaration, without requiring parameter labels 
> to be part of the type system (allowing, e.g. the operator + to be passed 
> into something that requires parameter labels).
>
>
> Second, extend the rules for function types to allow parameter API labels *if 
> and only if* they are used as the type of a declaration that allows parameter 
> labels, and interpret them as a sugar form for providing those labels on the 
> underlying declaration.  This means that the example above could be spelled 
> as:
>
>var op : (lhs: Int, rhs: Int) -> Int// Nice declaration syntax
>x = op(lhs: 1, rhs: 2)  // Same as above
>
>// API name of parameter is “opToUse”, internal name is "op(lhs:,rhs:)”.
>func foo(opToUse op : (lhs: Int, rhs: Int) -> Int) {
>  x = op(lhs: 1, rhs: 2) // Same as above.
>}
>foo(opToUse: +)  // Same as above.
>
>
> These two steps will provide the simple and expressive design approach that 
> we have now, without all of the problems that representing parameter labels 
> in the type system 

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[T.J. Usiyan via swift-evolution]

I noticed this immediately and assumed that it was recognized as suboptimal
but tolerable for now. The required underscores were meant to leave space
for improvement in this regard, no? If not… sad face.

TJ

On Tue, Oct 4, 2016 at 12:21 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> SE-0111 established that Swift's type system would not allow function
> argument labels to be expressed as part of a function type. As I've been
> working with curried functions, I'm discovering an unintended consequence
> of this proposal in that it strips curried functions of their external
> labels and the resulting calls of their readability.
>
> ```
> public func projected(
> function f: @escaping (CGFloat) -> CGFloat) ->
> (_ p0: CGPoint, _ p1: CGPoint) ->
> (_ percent: CGFloat) -> CGPoint
> {
> ```
>
> Calling the first level of currying still reads acceptably:
>
> ```
> let projectedFunction = projected(function: fToApply)
> ```
>
> But after that, the enforced label-less arguments mean all further
> semantics have to stay within the name of the assigned partially applied
> function symbol and all arguments must be supplied without meaning, which
> is not in the spirit of API guidelines or under the umbrella of Swiftiness:
>
> ```
> let fixedFunction = projectedFunction(p0, p1)
> let value = fixedFunction(0.2)
> ```
>
> There's no way to give either the line segment start and end points or the
> percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does
> not provide any support for documenting the roles of each curried return
> type.
>
> Could this be addressed specifically for currying or has the boat sailed
> forever on this topic?
>
> -- E
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Goffredo Marocchi via swift-evolution]

I do not think the boat has sailed. I do remember this issue being actually 
revisited after initial approval because of the impact it had and quite a few 
members in this list, myself included, thought it was not helping readability 
and clarity and that it was strange this came after putting so much emphasis on 
argument labels for methods... and rightfully so.

>From what I remember Chris L. said the actual state of things is not how the 
>final solution of the problem will look like, but that for Swift 3.0 they 
>needed to simplify how argument labels were treated as part of the type system 
>and short term needs won, but that the team agreed that the solution had to be 
>revisited and solved. I will try to look for that message.

Sent from my iPhone

> On 4 Oct 2016, at 17:21, Erica Sadun via swift-evolution 
>  wrote:
> 
> SE-0111 established that Swift's type system would not allow function 
> argument labels to be expressed as part of a function type. As I've been 
> working with curried functions, I'm discovering an unintended consequence of 
> this proposal in that it strips curried functions of their external labels 
> and the resulting calls of their readability.
> 
> ```
> public func projected(
> function f: @escaping (CGFloat) -> CGFloat) ->
> (_ p0: CGPoint, _ p1: CGPoint) -> 
> (_ percent: CGFloat) -> CGPoint
> {
> ```
> 
> Calling the first level of currying still reads acceptably:
> 
> ```
> let projectedFunction = projected(function: fToApply)
> ```
> 
> But after that, the enforced label-less arguments mean all further semantics 
> have to stay within the name of the assigned partially applied function 
> symbol and all arguments must be supplied without meaning, which is not in 
> the spirit of API guidelines or under the umbrella of Swiftiness:
> 
> ```
> let fixedFunction = projectedFunction(p0, p1)
> let value = fixedFunction(0.2)
> ```
> 
> There's no way to give either the line segment start and end points or the 
> percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
> provide any support for documenting the roles of each curried return type.
> 
> Could this be addressed specifically for currying or has the boat sailed 
> forever on this topic?
> 
> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Michael Ilseman via swift-evolution]

> On Oct 4, 2016, at 9:32 AM, Michael Ilseman via swift-evolution 
>  wrote:
> 
>> 
>> On Oct 4, 2016, at 9:21 AM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> SE-0111 established that Swift's type system would not allow function 
>> argument labels to be expressed as part of a function type. As I've been 
>> working with curried functions, I'm discovering an unintended consequence of 
>> this proposal in that it strips curried functions of their external labels 
>> and the resulting calls of their readability.
>> 
>> ```
>> public func projected(
>> function f: @escaping (CGFloat) -> CGFloat) ->
>> (_ p0: CGPoint, _ p1: CGPoint) -> 
>> (_ percent: CGFloat) -> CGPoint
>> {
>> ```
>> 
>> Calling the first level of currying still reads acceptably:
>> 
>> ```
>> let projectedFunction = projected(function: fToApply)
>> ```
>> 
>> But after that, the enforced label-less arguments mean all further semantics 
>> have to stay within the name of the assigned partially applied function 
>> symbol and all arguments must be supplied without meaning, which is not in 
>> the spirit of API guidelines or under the umbrella of Swiftiness:
>> 
>> ```
>> let fixedFunction = projectedFunction(p0, p1)
>> let value = fixedFunction(0.2)
>> ```
>> 
>> There's no way to give either the line segment start and end points or the 
>> percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
>> provide any support for documenting the roles of each curried return type.
>> 
>> Could this be addressed specifically for currying or has the boat sailed 
>> forever on this topic?
>> 
> 
> This could be expressed by allowing local variable names to have compound 
> names when of function type. I would not require it to be expressed this way, 
> but it would be a nice addition. This would look something like the following:
> 
> let projectedFunction(from:to:) = projected(function: fToApply)
> let scale(by:) = projectedFunction(from: myPoint1, to: myPoint2)
> let finalPoint = scale(by: 3.0)
> 
> When it comes to local assignment, it makes sense to allow local control over 
> argument labels. For people who don’t care to have their closures be applied 
> with labels, maybe allow current syntax:
> 
> let projectedFunction = projected(function: fToApply)
> let scale = projectedFunction(myPoint1, myPoint2)
> let finalPoint = scale(3.0)
> 
> I’m not sure if we want to force compound names always (demonstrate arity and 
> explicit label-less-ness), but one could envision a strict enforcement like:
> 
> let projectedFunction(_:_:) = projected(function: fToApply)
> let scale(_:) = projectedFunction(myPoint1, myPoint2)
> let finalPoint = scale(3.0)
> 

To clarify, I’m not in favor of strict enforcing of this final form, and it 
would need extreme justification to make that pitch. But, it might be possible 
to encourage that form in linting tools. And, if there is strong, albeit not 
extreme, justification, enforce through a warning/fix-it).


> 
> Probably out of scope for Swift 4 stage 1
> 
> 
>> -- E
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Michael Ilseman via swift-evolution]

> On Oct 4, 2016, at 9:21 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> SE-0111 established that Swift's type system would not allow function 
> argument labels to be expressed as part of a function type. As I've been 
> working with curried functions, I'm discovering an unintended consequence of 
> this proposal in that it strips curried functions of their external labels 
> and the resulting calls of their readability.
> 
> ```
> public func projected(
> function f: @escaping (CGFloat) -> CGFloat) ->
> (_ p0: CGPoint, _ p1: CGPoint) -> 
> (_ percent: CGFloat) -> CGPoint
> {
> ```
> 
> Calling the first level of currying still reads acceptably:
> 
> ```
> let projectedFunction = projected(function: fToApply)
> ```
> 
> But after that, the enforced label-less arguments mean all further semantics 
> have to stay within the name of the assigned partially applied function 
> symbol and all arguments must be supplied without meaning, which is not in 
> the spirit of API guidelines or under the umbrella of Swiftiness:
> 
> ```
> let fixedFunction = projectedFunction(p0, p1)
> let value = fixedFunction(0.2)
> ```
> 
> There's no way to give either the line segment start and end points or the 
> percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
> provide any support for documenting the roles of each curried return type.
> 
> Could this be addressed specifically for currying or has the boat sailed 
> forever on this topic?
> 

This could be expressed by allowing local variable names to have compound names 
when of function type. I would not require it to be expressed this way, but it 
would be a nice addition. This would look something like the following:

let projectedFunction(from:to:) = projected(function: fToApply)
let scale(by:) = projectedFunction(from: myPoint1, to: myPoint2)
let finalPoint = scale(by: 3.0)

When it comes to local assignment, it makes sense to allow local control over 
argument labels. For people who don’t care to have their closures be applied 
with labels, maybe allow current syntax:

let projectedFunction = projected(function: fToApply)
let scale = projectedFunction(myPoint1, myPoint2)
let finalPoint = scale(3.0)

I’m not sure if we want to force compound names always (demonstrate arity and 
explicit label-less-ness), but one could envision a strict enforcement like:

let projectedFunction(_:_:) = projected(function: fToApply)
let scale(_:) = projectedFunction(myPoint1, myPoint2)
let finalPoint = scale(3.0)


Probably out of scope for Swift 4 stage 1


> -- E
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

[Erica Sadun via swift-evolution]

SE-0111 established that Swift's type system would not allow function argument 
labels to be expressed as part of a function type. As I've been working with 
curried functions, I'm discovering an unintended consequence of this proposal 
in that it strips curried functions of their external labels and the resulting 
calls of their readability.

```
public func projected(
function f: @escaping (CGFloat) -> CGFloat) ->
(_ p0: CGPoint, _ p1: CGPoint) -> 
(_ percent: CGFloat) -> CGPoint
{
```

Calling the first level of currying still reads acceptably:

```
let projectedFunction = projected(function: fToApply)
```

But after that, the enforced label-less arguments mean all further semantics 
have to stay within the name of the assigned partially applied function symbol 
and all arguments must be supplied without meaning, which is not in the spirit 
of API guidelines or under the umbrella of Swiftiness:

```
let fixedFunction = projectedFunction(p0, p1)
let value = fixedFunction(0.2)
```

There's no way to give either the line segment start and end points or the 
percent-of-progress arguments any labels.  Further, Xcode/QuickHelp does not 
provide any support for documenting the roles of each curried return type.

Could this be addressed specifically for currying or has the boat sailed 
forever on this topic?

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution