[Review] SE-0111: Remove type system significance of function argument labels

I’d also like to know what the answer to this is before giving my vote for or against the proposal.

···

On 30 Jun 2016, at 20:37, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

This mostly makes sense to me and it seems like mostly a good idea, but take this example:

func doSomething(x: Int, y: Int) -> Bool { return true }
let x = doSomething
x(10, 10)

Is it then legal to do this?:

x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10)

That would seem odd to me. Maybe it could be useful, but it might also be *super* confusing. I’m not sure I have a suggestion as to what to do in a situation like this - but it doesn’t seem “right” to allow it.

l8r
Sean

On Jun 30, 2016, at 1:26 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:

  swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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

This mostly makes sense to me and it seems like mostly a good idea, but take this example:

func doSomething(x: Int, y: Int) -> Bool { return true }
let x = doSomething
x(10, 10)

Is it then legal to do this?:

x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10)

Why this should be legal? The type of x does not contain definition of `blahblah` and `totallyOffTheWallLabelThatDoesNotAppearANYWHERE` as labels.
So, I believe there no reasons to allow using of labels that was not explicitly declared.

···

On 30.06.2016 21:37, Sean Heber via swift-evolution wrote:

That would seem odd to me. Maybe it could be useful, but it might also be *super* confusing. I’m not sure I have a suggestion as to what to do in a situation like this - but it doesn’t seem “right” to allow it.

l8r
Sean

On Jun 30, 2016, at 1:26 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:

  swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
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

What is your evaluation of the proposal?

-1. Argument labels can have meaning and are very useful, especially for default parameter names in closures:

func handleResponse(handler: (response: Response) -> ())

// Callsite
handleResponse { response in // response automatically implied as the parameter name, clarifying usage.
 ...
}

I’d prefer we leave the existing behavior or consider the alternative solution to prohibit implicit subtyping.

Does this proposal fit well with the feel and direction of Swift?

I don’t feel that it does. I’ve always felt that being able to declare function types with named parameters was a powerful feature that allowed more expressivity in the language.

``` // Clear that the first String argument is the message and that the second is the sender
let messageHandler: (message: String, sender: String) -> ()

// Not clear what these parameters are
let messageHandler: (String, String) -> ()```

Would a way of specifying argument labels as part of the variable name help? That is, making variables have compound names like functions when they have function type? E.g.

let messageHandler(message:sender:) : (String, String) -> ()

Or more commonly,

let messageHandler(message:sender:) = … // something resulting in type (String, String) -> ()

This would achieve the goal of taking labels out of types, but still have them present and relevant as part of names.

···

On Jul 1, 2016, at 7:37 AM, Brad Hilton via swift-evolution <swift-evolution@swift.org> wrote:

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The closest comparison I can think of are Objective-C selectors, but these are more powerful and type-safe. I think it’s a real strength of the language.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading, and I have used function declarations with and without labels extensively.

Hello Swift community,

The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:

swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

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

Sorry, this was meant to be in response to:

From James F

···

On 2 Jul 2016, at 04:02, James Froggatt <james.froggatt@me.com> wrote:

I've made a separate topic discussing the possible consequences of this change, but I don't think the implications are really worth it. Parameter lists and tuples are fundamentally similar, and that's why we're getting all of these confusing edge cases.

Ultimately, this come down to two problems:

• Casting between functions of different labels is confusing. We've discussed removing argument labels from function types for this reason. However, tuples have this exact same problem. We should solve this generally, for tuples and functions. A solution applicable to one is applicable to the other. If tuples were only in the languages because they were meant to model a function's arguments, I believe they still do in Swift 2.

Perhaps a tuple's argument labels should be in the name of it's containing variable, like we plan for function types?

• Parameter lists have distinct annotations, which are unsuitable for full exposure to the type system. However, I think this can be resolved through something similar to the @noescape annotation, but for tuples, to restrict them to ‘pure, nonescaping’ functional contexts (IE direct application to a function).

For example:

apply<A, B>(in: @params A, function: A -> B) -> B {
   return function(in)
}

//since we know the tuple cannot escape,
//only be passed to more functions with the exact parameter list represented by A,
//we can safely use it with parameter decorations in a strictly functional context:

apply(in: (&mutable, other), function: aFunction)

//or more practically:

(&mutable, other) => aFunction

Any return value is naturally escaping, meaning a returned tuple cannot have modifiers such as @noescape and inout, since it can't provide that guarantee. I think this addresses the problem much more directly.

There are inherently parallels between parameter lists and tuples, and that's why functional programming languages rely on them. Swift actually has quite a limited number of parameter list modifiers, so I think it's worth exploring alternatives to fit these into the existing, much more generalised system, before removing the parallel between parameter lists and tuples in favour of something already known to be less flexible.

My review is inline.

On 30 Jun 2016, at 19:26, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:

  swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

Strongly against, for the reasons described.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, but we should explore the alternatives.

  * Does this proposal fit well with the feel and direction of Swift?

Absolutely not, we will lose fundamental to Swift something by making this change. We've already seen it by ‘removing’ tuple splat, and finding it to be only surface-level. This is something already deeply ingrained in the type system, and which provides a good deal of flexibility to functional code. The addition of Never in favour of @noreturn shows how powerful the type system can be, and I don't think we should walk this path half-heartedly.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I got started programming back in Objective-C, but most of my programming experience is with Swift. In the various other (admittedly older) imperative languages I've tried, I have been disappointed by the inflexibility of things such as:

• Lack of tuple support, for straightforward return of >1 value where a formal type is overkill.
• Lack of explicit optionals, or tacked-on optional support which interacts poorly with generics and existing libraries.
• Lack of equal support for value-types, to varying degrees.
• Generics aren't actually generic, often requiring overloads for value-types, due to their ‘defaulting’ behaviour.

The one thing these all have in common is the type system. There seems to be real progress to be made by generalizing the type system as Swift has, so far.

Swift's functional generics system is incredible, largely thanks to the modelling of parameter lists as a type, namely tuples. While this model has fallen behind language advances, I think it can and should be brought up to speed.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A lot of thought, while working with Swift and other languages.

Thanks for reading.

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

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

Overall, -1.

I agree that labels should not affect the type, but imho the current status (Swift 2.3 — I haven't checked Version 3) is fine, and the proposal doesn't achieve what it says in the title:
For me, that is no question of types at all, but only of names:

var a: (Int, z: Int) -> Void = t
var b: (y: Int, z: Int) -> Void = t

a = b

This works, because a and b are both of type (Int, Int) -> Void, and the labels aren't significant.

The point of the behavior is to remove the subtyping relationships from the type system which make the above work, which is a very real change.

So the proposal merely disallows labels in the declaration of function variables, which I consider bad, because labels convey the meaning of parameters. Why should something that is widely seen as a good feature of functions be removed from function variables?

As has been discussed exhaustively in this thread, Swift 3 function labels don't convey the meaning of parameters, they are almost always prepositional phrases that don't make sense apart from the primary function name they are attached to.

···

On Jul 3, 2016, at 11:50 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

If you share the opinion that labels are part of the name, the battleship example no good argument against labels:
No one stops you from doing

let minimum: (Int, Int) -> Int = max
Which is confusing as well.

Best regards,
Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Ever considered looking at how typescript handles argument names in object literal deconstruction?

Regards
(From mobile)

···

On Jul 3, 2016, at 10:36 PM, Pyry Jahkola via swift-evolution <swift-evolution@swift.org> wrote:

On 30 Jun 2016, Chris Lattner wrote:

The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:

  swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub

What is your evaluation of the proposal?

+1. With the way the community has settled using argument labels, it seems clear to me that argument labels are part of a function's name and should not affect its type.

What we currently have technically works because the compiler is quite lenient in type conversions between different argument labels. But since there are corner cases lurking where labels in the function type matter (as demonstrated in the proposal), it's best we get rid of them entirely for clarity. As it has been pointed out, the status quo also complicates the overload resolution process and causes confusing error messages when the compiler can't tell if your argument labels are wrong or argument types. We're better without that complexity.

Further, I think removing this oddity could make function application with tuples feasible again (a.k.a the simple form of "tuple splatting" with all arguments in the tuple) by requiring to fully name the function before passing the arguments tuple:

    func doSomething(x: Int, y: Int) -> Bool { return true }
    func doSomething(any: Any) -> Bool { return false } // This can't possibly be considered below.
    
    let args = (1, 2)
    let named = (x: 1, y: 2)
    let f = doSomething(x:y:)
    f(args) // Unambiguous call, if the syntax is made legal (again).
    doSomething(x:y:)(args) // So is this.
    doSomething(args) // This would still be an error as per SE-0029.
    let tuples = [(1, 2), (3, 4), (5, 6)]
    print(tuples.map(f)) // This would be allowed. (Confusingly it already works despite SE-0029!)

In particular, you couldn't apply a `func` function with a tuple (which was what SE-0029 removed) but you could apply a qualified function reference (SE-0021) as well as a function value (i.e. a named closure) with a tuple, because both of them have set in stone their argument list length before the tuple application and thus suffer from none of the disadvantages listed in the motivation for SE-0029. That would of course need a separate proposal and can be delayed until Swift 3 has been released.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

I think so.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Well, we've had argument labels in Objective-C but since it's not a strongly typed language I don't think it applies for comparison. However, I naturally feel argument labels in Objective-C as well are part of the function's name rather than its type.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More than a quick reading. I've suggested a similar idea before but didn't motivate it well enough to gain interest back then. Big thanks to Austin for driving it forward this time!

— Pyry

PS. Can anybody explain why the last example in my code above turned out to be allowed even though SE-0029 seems to prohibit it? Here's a more comprehensive test which made me positively surprised that it still worked after SE-0029:

    let f: (Int, Int) -> Int = (+)
    let x = (1, 2)
    let x, y = (3, 4)
    f(1, 2) //=> 3
    // f((1, 2)) // Does not compile, as expected (SE-0029).
    // f(x) // Does not compile, as expected.
    [x, y].map(f) //=> [3, 7] // Surprisingly compiles, but why?
    let g: ((Int, Int)) -> Int = f // Huh? So `f` can coerce to a `(tuple) -> Int`?
    g(x) //=> 3 // So this is what made `map` work above.
    (f as ((Int, Int)) -> Int)(x) //=> 3 // This works too, didn't expect it to.
    [x, y].map(+) //=> [3, 7] // Finally, why is this allowed despite SE-0029?

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

As has been discussed exhaustively in this thread, Swift 3 function labels don't convey the meaning of parameters, they are almost always prepositional phrases that don't make sense apart from the primary function name they are attached to.

Why should there be different rules for closures and regular functions?
If labels are considered useful, they are useful in both contexts, and it should not be forbidden to have labels for closure parameters.

The only thing I don't like now is that labels are added when the type is inferred; imho that doesn't make sense in deed, and it would be more consistent to strip them (when labels are part of the name, this is like silently changing variable names to match Hungarian notation ;-).

I'd hardly oppose anything that simplifies the type system, so I agree with Brent that it is ok to remove them first to re-introduce them in a better form later.

  * What is your evaluation of the proposal?

I agree that the current situation is incoherent. If the type system doesn't care about the labels, the labels probably shouldn't be in the type.

In the long run, it must be possible to label the parameters of a closure. But that labeling does not *necessarily* belong on the type; it could go on the name:

  // Old and busted
  let completion: (records: [Record]?, error: Error?) -> Void
  // New hotness
  let completion(records:error:): ([Record]?, Error?) -> Void

I really like this idea. Clearly separated "name" and "type" of the function/closure just like for like for any other "simple" variable like `let value: Int`
The only note : I believe we should be still allowed to define func variable without labels, if I don't care about them.

let completion: ([Record]?, Error?) -> Void

And I don't think it would be terrible to remove the labels from the type before we add them to the name.

Support. But it will be great if we'll have both at the same time.

On the other hand, we could go the other direction and make the labels significant. Or—to address the `remove(from:)`/`add(to:)` critique—we could perhaps make the *internal* names significant, while considering the internal labels as part of the variable name. (Presumably both `remove(from:)` and `add(to:)` would be of type `(collection: WidgetCollection) -> Void`.)

I don't feel like this is correct direction. For me parameter labels definitely belongs to name of func variable, not to type.

···

On 04.07.2016 14:17, Brent Royal-Gordon via swift-evolution wrote:

Both options are sensible; the status quo is not. We should choose a direction and start going that way.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The type system is being a bit nonsensical here.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. Swift 3, breaking everything now, etc.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Can't really think of much that's comparable.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

How does this proposal agree with tuple labels? Compare:

func find(array: [Int], value: Int) -> (index: Int, value: Int)
let result = find(...)
result.index //=> 0

func getHandler(for kind: EventKind) -> (event: Event, parent: Widget) -> ()
let result = getHandler(...)
result(event: ..., parent: ...)

We are going to prohibit second without removing the first; how is that
consistent?

···

2016-07-04 14:17 GMT+03:00 Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org>:

> * What is your evaluation of the proposal?

I agree that the current situation is incoherent. If the type system
doesn't care about the labels, the labels probably shouldn't be in the type.

In the long run, it must be possible to label the parameters of a closure.
But that labeling does not *necessarily* belong on the type; it could go on
the name:

        // Old and busted
        let completion: (records: [Record]?, error: Error?) -> Void
        // New hotness
        let completion(records:error:): ([Record]?, Error?) -> Void

And I don't think it would be terrible to remove the labels from the type
before we add them to the name.

On the other hand, we could go the other direction and make the labels
significant. Or—to address the `remove(from:)`/`add(to:)` critique—we could
perhaps make the *internal* names significant, while considering the
internal labels as part of the variable name. (Presumably both
`remove(from:)` and `add(to:)` would be of type `(collection:
WidgetCollection) -> Void`.)

Both options are sensible; the status quo is not. We should choose a
direction and start going that way.

> * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes. The type system is being a bit nonsensical here.

> * Does this proposal fit well with the feel and direction of Swift?

Yes. Swift 3, breaking everything now, etc.

> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

Can't really think of much that's comparable.

> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

Quick reading.

--
Brent Royal-Gordon
Architechies

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

They already *are* type compatible. This works right now:

var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage
a = sinkBattleship
// ???
a(ofHits: 1, forRuns: 2)

Your proposal does not make it clear that this works (which is surprising to me).

I would argue the proposal the other way: that there should be an error on line 2, and this should not be permitted implicitly.

Scott

This is a false dichotomy. The language can support tuples without
requiring that function application be modeled in terms of tuples. That
ship has sailed long ago, and there is no reason to revisit it without a
compelling reason (and "function argument lists look sort of like tuples"
is not to me compelling).

As for the label semantics, Swift's current behavior is actively
misleading, please see the example in the prior email. There are no
meaningful semantics in the label, because implicit conversion between
differently-labeled function types means that there is no way to usefully
enforce these invariants to begin with.

···

On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote:

On 30 Jun 2016, at 21:20, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> wrote:

> On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of "SE-0111: Remove type system significance of function
argument labels" begins now and runs through July 4. The proposal is
available here:
>
>
swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub
>
> * What is your evaluation of the proposal?

-1

> * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes, but I do not think that the proposed solution is the correct one.
Rather, one should aim for designing a proper tuple type. Right now, tuples
seem more like an afterthought even though they play a significant role in
the language. Proper tuple casting/extensions/tuple algebra will solve the
issues pointed out in this proposal, among other useful applications.

Taras, I don't believe this proposal touches tuples in any way. IIUC,
argument lists are no longer tuples and have not been for a long time, and
there is no intention on the part of the core team to return to that state
of affairs.

Still, there is a clear correspondence between tuples and argument lists.
I though that the model of functions as maps from tuples to tuples was very
elegant, but I understand why this model was dropped. However tuples seem
to be somehow misplaced right now, and this fact resonates through the
entire language system (function types, enums, pattern matching etc.). I
think one should stop and reconsider tuple status first to get a sense of a
‚grand strategy‘ for Swift. I am worried that small changes like this
proposal attempt to deal with the ripples cast by a much deeper problem
instead of the problem itself. As far as I am considered, there are two
basic options. Either say, well, tuples were a nice idea, but it doesn’t
really work out — and then consistently apply this to the entire language.
Or, reinstate that tuples are a modelling construct on which a lot of
language concepts are based and try to fix the underlaying limitations.
Function arguments don’t need to be tuples formally. However, why not have
a casting system that allows one to transform between function signatures
and tuple types? That would certainly solve the deficients Swift is
experiencing now as well as allow greater flexibility in the future.

And orthogonally to the tuple topic, I think that argument labels carry
meaningful semantics and are much more than just cosmetic devices.
Accepting this proposal would make the language weird. The deeper
connection between the semantics of the argument list and the exposed type
would be disturbed.

Hope any of this has made any sense :)

> * Does this proposal fit well with the feel and direction of
Swift?

I do not believe so

> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A glance

_______________________________________________
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

I would think that the naming guidelines are an argument for reducing the
role of argument labels, if any.

This labeled tuple makes sense, because 'x' and 'y' describe the semantic
meaning of each element (Int which represents an x-coordinate):

let myTuple: (x: Int, y: Int)

This also makes sense, because 'hits' and 'runs' describe the semantic
meaning of each argument (Int which represents number of hits):

let a : (hits: Int, runs: Int) -> Bool

This makes absolutely no sense to me:

let b: (ofHits: Int, forRuns: Int) -> Bool

In fact, 'b' is a better example than the average, because of the naming
guideline point to spell out the semantics of weakly typed arguments in the
argument label.

func getWidget(for provider: Provider, with manifest: ShippingManifest) ->
Widget { /* ... */ }

let widgetGetter : (for: Provider, with: ShippingManifest) = getWidget

At this point, the labels are completely superfluous. They make no sense
except in the context of a method name, because they are prepositional
phrases. Knowing that the Provider is "for" something and something does
something "with" the ShippingManifest is absolutely useless to anyone
reading the code where the method name those labels are part of isn't
immediately obvious.

Austin

···

On Thu, Jun 30, 2016 at 3:33 PM, Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution < > swift-evolution@swift.org> wrote:

-1

This proposal doesn’t even use Swift naming style to make its point, as
soon as you do, the reason why Swift considers argument labels to be part
of the type signature becomes apparent.

The author of the proposal uses the following example:

func doSomething(x: Int, y: Int) -> Bool

This is just not Swift-y, a much better example would be:

func sinkBattleship(atX x: Int, y: Int) -> Bool

<pedanticism>
If you want to talk about pedantic following of API naming guidelines for
example code, then I believe that your example also runs afoul. It would be:

func sinkBattleshipAt(x: Int, y: Int) -> Bool

Due to a special case where the preposition covers multiple arguments.
This arrises mostly from flatten-ed structs as parameters, e.g. from old C
APIs predating struct literal syntax. See:

   -

   An exception arises when the first two arguments represent parts of a
   single abstraction.

   a.move(*toX:* b, *y:* c)
   a.fade(*fromRed:* b, *green:* c, *blue:* d)

   In such cases, begin the argument label *after* the preposition, to
   keep the abstraction clear.

   a.moveTo(*x:* b, *y:* c)
   a.fadeFrom(*red:* b, *green:* c, *blue:* d)

</pedanticism>

the proposal states that the argument labels be then stripped from the
type, which would make this method type-compatible with:

func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool

I don’t think it’s desirable for this to work at all… Argument labels are
not parameter names, they are a first class part of Swift’s type system,
and always meaningful when employed properly.

Scott
_______________________________________________
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

I’d prefer to tighten the system so that the above no longer compiles, rather than make it even more permissive.

-1.

Charles

···

On Jun 30, 2016, at 1:50 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Jun 30, 2016 at 11:43 AM, Scott James Remnant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1

This proposal doesn’t even use Swift naming style to make its point, as soon as you do, the reason why Swift considers argument labels to be part of the type signature becomes apparent.

The author of the proposal uses the following example:

  func doSomething(x: Int, y: Int) -> Bool

This is just not Swift-y, a much better example would be:

  func sinkBattleship(atX x: Int, y: Int) -> Bool

the proposal states that the argument labels be then stripped from the type, which would make this method type-compatible with:

  func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool

They already *are* type compatible. This works right now:

var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage
a = sinkBattleship
// ???
a(ofHits: 1, forRuns: 2)

[Proposal: swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub ]

This is my feeling as well. Argument labels are definitely part of the name of the function, but they aren’t part of the type. A few functions happen to have argument labels

On future directions: I’m mildly in favor of allowing parameters and locals with closure type to have labels in the name:

func map<Result>(_ transform(from:): (Element) -> Result) -> [Result]
func map<Result>(_ transform: (from: Element) -> Result) -> [Result]

which, yes, would require you to rewrite the names if you cared, but would at least allow you to rewrite the names if you cared. More importantly, it lets you document callbacks properly. (This kind of works by coincidence today.)

This *might* make sense. I almost included something similar in my review. It is one of the use cases I had in mind when I mentioned the possibility of designing a less fragile feature for specific uses cases. But that discussion is for the future. :)

···

On Jun 30, 2016, at 9:36 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

I am in favor of this proposal.

Jordan

On Jun 30, 2016, at 11:44, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a good point. I feel like calling `x` with any sort of argument labels should be prohibited. I don't think there's any expressivity penalty for doing so (especially since tuple splat is gone); plus, once a function is reified as a value (as opposed to being invoked by naming it directly), I think the most principled thing to do is to consider the argument labels "erased".

(There might be an alternate universe in which Swift's function types' argument labels are *fully* significant by disallowing conversions between function values declared with different argument labels, but Swift has never actually enforced such a requirement, and so it's probably better to just formalize the semantics as described above than vacillating on whether argument labels are significant or not.)

Austin

On Thu, Jun 30, 2016 at 11:37 AM, Sean Heber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This mostly makes sense to me and it seems like mostly a good idea, but take this example:

func doSomething(x: Int, y: Int) -> Bool { return true }
let x = doSomething
x(10, 10)

Is it then legal to do this?:

x(blahblah:10, totallyOffTheWallLabelThatDoesNotAppearANYWHERE: 10)

That would seem odd to me. Maybe it could be useful, but it might also be *super* confusing. I’m not sure I have a suggestion as to what to do in a situation like this - but it doesn’t seem “right” to allow it.

l8r
Sean

> On Jun 30, 2016, at 1:26 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hello Swift community,
>
> The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:
>
> swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub
>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> swift-evolution/process.md at master · apple/swift-evolution · GitHub
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

As for the label semantics, Swift's current behavior is actively misleading, please see the example in the prior email. There are no meaningful semantics in the label, because implicit conversion between differently-labeled function types means that there is no way to usefully enforce these invariants to begin with.

That is a good point. I admit to not knowing this (I strongly expected that labels would be semantically meaningful). But what exactly is the status of the argument labels than in Swift? Just a documentation device for the programmer and a hint for the compiler to do function dispatch? But if the compiler indeed does dispatch on argument labels, then they are not completely void of semantics, are they? As I mentioned before, I think the problem here is much deeper.

The state of affairs I would prefer is something along these lines:

1. Labels are semantically meaningful
2. There is an explicit casting system for function signatures
3. This casting system should be in close correspondence to tuples. The "function argument lists look sort of like tuples“ is a very compelling reason actually, because of the principle of the least surprise. If I have two things in the language that look very similar, then its very confusing if they exhibit very different behaviour. Again, I am not proposing that one goes back to model functions in terms of tuples. But as long as there is a surface resemblance (and an obvious morphisms between the two), at least some aspects of their design should be kept in sync.

But again, this touches on some deep design decisions for the language, so I — as an amateur — don’t feel in my plate discussing this here. I believe that there currently might be some inconsistencies in the language design that should be sealed with (but maybe they are no inconsistencies at all and I simply have false expectations).

Best,

Taras

···

On 30 Jun 2016, at 22:11, Austin Zheng <austinzheng@gmail.com> wrote:

On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 30 Jun 2016, at 21:20, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:

On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hello Swift community,
>
> The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:
>
> swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub
>
> * What is your evaluation of the proposal?

-1

> * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, but I do not think that the proposed solution is the correct one. Rather, one should aim for designing a proper tuple type. Right now, tuples seem more like an afterthought even though they play a significant role in the language. Proper tuple casting/extensions/tuple algebra will solve the issues pointed out in this proposal, among other useful applications.

Taras, I don't believe this proposal touches tuples in any way. IIUC, argument lists are no longer tuples and have not been for a long time, and there is no intention on the part of the core team to return to that state of affairs.

Still, there is a clear correspondence between tuples and argument lists. I though that the model of functions as maps from tuples to tuples was very elegant, but I understand why this model was dropped. However tuples seem to be somehow misplaced right now, and this fact resonates through the entire language system (function types, enums, pattern matching etc.). I think one should stop and reconsider tuple status first to get a sense of a ‚grand strategy‘ for Swift. I am worried that small changes like this proposal attempt to deal with the ripples cast by a much deeper problem instead of the problem itself. As far as I am considered, there are two basic options. Either say, well, tuples were a nice idea, but it doesn’t really work out — and then consistently apply this to the entire language. Or, reinstate that tuples are a modelling construct on which a lot of language concepts are based and try to fix the underlaying limitations. Function arguments don’t need to be tuples formally. However, why not have a casting system that allows one to transform between function signatures and tuple types? That would certainly solve the deficients Swift is experiencing now as well as allow greater flexibility in the future.

And orthogonally to the tuple topic, I think that argument labels carry meaningful semantics and are much more than just cosmetic devices. Accepting this proposal would make the language weird. The deeper connection between the semantics of the argument list and the exposed type would be disturbed.

Hope any of this has made any sense :)

> * Does this proposal fit well with the feel and direction of Swift?

I do not believe so

> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A glance

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

  * What is your evaluation of the proposal?

I agree that the current situation is incoherent. If the type system doesn't care about the labels, the labels probably shouldn't be in the type.

In the long run, it must be possible to label the parameters of a closure. But that labeling does not *necessarily* belong on the type; it could go on the name:

  // Old and busted
  let completion: (records: [Record]?, error: Error?) -> Void
  // New hotness
  let completion(records:error:): ([Record]?, Error?) -> Void

I really like this idea. Clearly separated "name" and "type" of the function/closure just like for like for any other "simple" variable like `let value: Int`
The only note : I believe we should be still allowed to define func variable without labels, if I don't care about them.

let completion: ([Record]?, Error?) -> Void

And I don't think it would be terrible to remove the labels from the type before we add them to the name.

Support. But it will be great if we'll have both at the same time.

The question is how is this affecting current code base? Remove the labels for Swift 3 and then adding them back in subsequent Swift release - but the labels are already removed from the code... Is this really something we need to have *right now*, instead of waiting for a bit and adding an automatic migration?

I know it's a code-breaking change, but I don't think Swift 3.x or Swift 4 will be completely 100% code-compatible, even though it's one of the goals of Swift 3 to make as many code-breaking changes as possible...

···

On Jul 4, 2016, at 1:36 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 04.07.2016 14:17, Brent Royal-Gordon via swift-evolution wrote:

On the other hand, we could go the other direction and make the labels significant. Or—to address the `remove(from:)`/`add(to:)` critique—we could perhaps make the *internal* names significant, while considering the internal labels as part of the variable name. (Presumably both `remove(from:)` and `add(to:)` would be of type `(collection: WidgetCollection) -> Void`.)

I don't feel like this is correct direction. For me parameter labels definitely belongs to name of func variable, not to type.

Both options are sensible; the status quo is not. We should choose a direction and start going that way.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The type system is being a bit nonsensical here.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. Swift 3, breaking everything now, etc.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Can't really think of much that's comparable.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

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

How does this proposal agree with tuple labels? Compare:

func find(array: [Int], value: Int) -> (index: Int, value: Int)
let result = find(...)
result.index //=> 0

func getHandler(for kind: EventKind) -> (event: Event, parent: Widget) -> ()
let result = getHandler(...)
result(event: ..., parent: ...)

We are going to prohibit second without removing the first; how is that
consistent?

I don't expect this will be changed, and expect this will work similar as for tuples, i.e. for me labels for arguments is just for declaration(for syntax), not for type of returned value: (Swift Ver. 3.0 (Jun 20, 2016))

func f() -> (index: Int, value: Int) { return (index: 1, value: 2) }

let result1 = f()
let result2 : (Int, Int) = f()

print(result1, result2) // (1, 2) (1, 2)
print(result1.index, result2.0) // 1 1
print(result1.dynamicType) // (Int, Int)
print(result1.dynamicType == result2.dynamicType) // true

typealias MyTuple = (x: Int, y: Int)

print(MyTuple.self == result1.dynamicType) // true

print("--------")

func getHandler(for kind: Int) -> (event: String, parent: String) -> () {
     return { event, parent in print(event, parent) }
}

var handler1 : (String, String) -> () = {_, _ in }
handler1 = getHandler(for: 0)
handler1("event1", "parent1")

let handler2 = getHandler(for: 0)
handler2(event: "event2", parent: "parent2")

print(handler1.dynamicType) // ((String, String)) -> ()
print(handler1.dynamicType == handler2.dynamicType) // true

func someFunc(name n: String, description d: String) {
     print("name/desc: ", n, d)
}

print(someFunc.dynamicType) // ((String, String)) -> ()

print(handler1.dynamicType == someFunc.dynamicType) // true

···

On 04.07.2016 16:33, Anton Zhilin via swift-evolution wrote:

2016-07-04 14:17 GMT+03:00 Brent Royal-Gordon via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

    > * What is your evaluation of the proposal?

    I agree that the current situation is incoherent. If the type system
    doesn't care about the labels, the labels probably shouldn't be in the
    type.

    In the long run, it must be possible to label the parameters of a
    closure. But that labeling does not *necessarily* belong on the type;
    it could go on the name:

            // Old and busted
            let completion: (records: [Record]?, error: Error?) -> Void
            // New hotness
            let completion(records:error:): ([Record]?, Error?) -> Void

    And I don't think it would be terrible to remove the labels from the
    type before we add them to the name.

    On the other hand, we could go the other direction and make the labels
    significant. Or—to address the `remove(from:)`/`add(to:)` critique—we
    could perhaps make the *internal* names significant, while considering
    the internal labels as part of the variable name. (Presumably both
    `remove(from:)` and `add(to:)` would be of type `(collection:
    WidgetCollection) -> Void`.)

    Both options are sensible; the status quo is not. We should choose a
    direction and start going that way.

    > * Is the problem being addressed significant enough to warrant
    a change to Swift?

    Yes. The type system is being a bit nonsensical here.

    > * Does this proposal fit well with the feel and direction of Swift?

    Yes. Swift 3, breaking everything now, etc.

    > * If you have used other languages or libraries with a similar
    feature, how do you feel that this proposal compares to those?

    Can't really think of much that's comparable.

    > * How much effort did you put into your review? A glance, a
    quick reading, or an in-depth study?

    Quick reading.

    --
    Brent Royal-Gordon
    Architechies

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto: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

This should probably be a motivating example.

I'll add an Alternative to keep the present behavior and tighten the
requirements.

Austin

···

On Thu, Jun 30, 2016 at 11:56 AM, Scott James Remnant <scott@netsplit.com> wrote:

> They already *are* type compatible. This works right now:
>
> var a : (ofHits: Int, forRuns: Int) -> Bool = meetsBattingAverage
> a = sinkBattleship
> // ???
> a(ofHits: 1, forRuns: 2)

Your proposal does not make it clear that this works (which is surprising
to me).

I would argue the proposal the other way: that there should be an error on
line 2, and this should not be permitted implicitly.

Scott

You might like the alternative I added (
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md\).
It basically goes the other way: keep the semantic significance of labels,
and make them mean something by prohibiting converting between different
function types with the same types but different labels.

···

On Thu, Jun 30, 2016 at 1:36 PM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

On 30 Jun 2016, at 22:11, Austin Zheng <austinzheng@gmail.com> wrote:

As for the label semantics, Swift's current behavior is actively
misleading, please see the example in the prior email. There are no
meaningful semantics in the label, because implicit conversion between
differently-labeled function types means that there is no way to usefully
enforce these invariants to begin with.

That is a good point. I admit to not knowing this (I strongly expected
that labels would be semantically meaningful). But what exactly is the
status of the argument labels than in Swift? Just a documentation device
for the programmer and a hint for the compiler to do function dispatch?
But if the compiler indeed does dispatch on argument labels, then they are
not completely void of semantics, are they? As I mentioned before, I think
the problem here is much deeper.

The state of affairs I would prefer is something along these lines:

1. Labels are semantically meaningful
2. There is an explicit casting system for function signatures
3. This casting system should be in close correspondence to tuples. The
"function argument lists look sort of like tuples“ is a very compelling
reason actually, because of the principle of the least surprise. If I have
two things in the language that look very similar, then its very confusing
if they exhibit very different behaviour. Again, I am not proposing that
one goes back to model functions in terms of tuples. But as long as there
is a surface resemblance (and an obvious morphisms between the two), at
least some aspects of their design should be kept in sync.

But again, this touches on some deep design decisions for the language, so
I — as an amateur — don’t feel in my plate discussing this here. I believe
that there currently might be some inconsistencies in the language design
that should be sealed with (but maybe they are no inconsistencies at all
and I simply have false expectations).

Best,

Taras

On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> wrote:

On 30 Jun 2016, at 21:20, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution < >> swift-evolution@swift.org> wrote:

> On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
> Hello Swift community,
>
> The review of "SE-0111: Remove type system significance of function
argument labels" begins now and runs through July 4. The proposal is
available here:
>
>
swift-evolution/0111-remove-arg-label-type-significance.md at master · apple/swift-evolution · GitHub
>
> * What is your evaluation of the proposal?

-1

> * Is the problem being addressed significant enough to warrant a
change to Swift?

Yes, but I do not think that the proposed solution is the correct one.
Rather, one should aim for designing a proper tuple type. Right now, tuples
seem more like an afterthought even though they play a significant role in
the language. Proper tuple casting/extensions/tuple algebra will solve the
issues pointed out in this proposal, among other useful applications.

Taras, I don't believe this proposal touches tuples in any way. IIUC,
argument lists are no longer tuples and have not been for a long time, and
there is no intention on the part of the core team to return to that state
of affairs.

Still, there is a clear correspondence between tuples and argument lists.
I though that the model of functions as maps from tuples to tuples was very
elegant, but I understand why this model was dropped. However tuples seem
to be somehow misplaced right now, and this fact resonates through the
entire language system (function types, enums, pattern matching etc.). I
think one should stop and reconsider tuple status first to get a sense of a
‚grand strategy‘ for Swift. I am worried that small changes like this
proposal attempt to deal with the ripples cast by a much deeper problem
instead of the problem itself. As far as I am considered, there are two
basic options. Either say, well, tuples were a nice idea, but it doesn’t
really work out — and then consistently apply this to the entire language.
Or, reinstate that tuples are a modelling construct on which a lot of
language concepts are based and try to fix the underlaying limitations.
Function arguments don’t need to be tuples formally. However, why not have
a casting system that allows one to transform between function signatures
and tuple types? That would certainly solve the deficients Swift is
experiencing now as well as allow greater flexibility in the future.

And orthogonally to the tuple topic, I think that argument labels carry
meaningful semantics and are much more than just cosmetic devices.
Accepting this proposal would make the language weird. The deeper
connection between the semantics of the argument list and the exposed type
would be disturbed.

Hope any of this has made any sense :)

> * Does this proposal fit well with the feel and direction of
Swift?

I do not believe so

> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a
quick reading, or an in-depth study?

A glance

_______________________________________________
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

I didn’t see the pre-proposal, and I apologize if this has come up elsewhere on this list, but did you consider the alternative where you must use the compound name to refer to a function? That is:

func foo(a: A, b: B) -> C
func bar(from: A, using: B) -> C
let higherOrderABToC: (A, B) -> C = foo(a:b:)
higherOrderABToC = bar(from:using:)

That is, “foo” by itself is an incomplete name, and you must provide the full compound name. This will penalize convenience of references to functions, though you will simplify the overloading logic of functions: two functions are not overloaded if their full compound names differ. This can be thought of as taking SE0021 and running wild, enforcing that all naming of functions use the compound name.

The notion of providing the name of a function with a full compound name is increasingly common in Swift, with SE0021 generalized naming, improvements to swift_name, SE0044 import-as-member, etc.

To modify the example from later in the proposal:

func doSomething(x: Int, y: Int) -> Bool {
    return x == y
}

func somethingElse(a: Int, b: Int) -> Bool {
    return a > b
}

// fn2's type is (Int, Int) -> Bool
var fn2 = doSomething(x:y:)

// Okay
fn2(1, 2)

// Okay
fn2 = somethingElse(a:b:)

The notion here, is that we’re not just dropping argument labels from the type system, but instead we’re hoisting such concerns into the syntax by making them an intrinsic part of the name. Then, if you bind to it with a value, that value of course wouldn’t be called with labels because labels are not part of its name.

If this is unwieldy, then it’s worth stating how this behaves in the presence of functions overloaded based on argument label alone, as Erica mentions.

···

On Jun 30, 2016, at 3:43 PM, Austin Zheng <austinzheng@gmail.com> wrote:

I would think that the naming guidelines are an argument for reducing the role of argument labels, if any.

This labeled tuple makes sense, because 'x' and 'y' describe the semantic meaning of each element (Int which represents an x-coordinate):

let myTuple: (x: Int, y: Int)

This also makes sense, because 'hits' and 'runs' describe the semantic meaning of each argument (Int which represents number of hits):

let a : (hits: Int, runs: Int) -> Bool

This makes absolutely no sense to me:

let b: (ofHits: Int, forRuns: Int) -> Bool

In fact, 'b' is a better example than the average, because of the naming guideline point to spell out the semantics of weakly typed arguments in the argument label.

func getWidget(for provider: Provider, with manifest: ShippingManifest) -> Widget { /* ... */ }

let widgetGetter : (for: Provider, with: ShippingManifest) = getWidget

At this point, the labels are completely superfluous. They make no sense except in the context of a method name, because they are prepositional phrases. Knowing that the Provider is "for" something and something does something "with" the ShippingManifest is absolutely useless to anyone reading the code where the method name those labels are part of isn't immediately obvious.

Austin

On Thu, Jun 30, 2016 at 3:33 PM, Michael Ilseman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jun 30, 2016, at 11:43 AM, Scott James Remnant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-1

This proposal doesn’t even use Swift naming style to make its point, as soon as you do, the reason why Swift considers argument labels to be part of the type signature becomes apparent.

The author of the proposal uses the following example:

func doSomething(x: Int, y: Int) -> Bool

This is just not Swift-y, a much better example would be:

func sinkBattleship(atX x: Int, y: Int) -> Bool

<pedanticism>
If you want to talk about pedantic following of API naming guidelines for example code, then I believe that your example also runs afoul. It would be:

func sinkBattleshipAt(x: Int, y: Int) -> Bool

Due to a special case where the preposition covers multiple arguments. This arrises mostly from flatten-ed structs as parameters, e.g. from old C APIs predating struct literal syntax. See:

An exception arises when the first two arguments represent parts of a single abstraction.

a.move(toX: b, y: c)
a.fade(fromRed: b, green: c, blue: d)
In such cases, begin the argument label after the preposition, to keep the abstraction clear.

a.moveTo(x: b, y: c)
a.fadeFrom(red: b, green: c, blue: d)

</pedanticism>

the proposal states that the argument labels be then stripped from the type, which would make this method type-compatible with:

func meetsBattingAverage(ofHits hits: Int, forRuns runs: Int) -> Bool

I don’t think it’s desirable for this to work at all… Argument labels are not parameter names, they are a first class part of Swift’s type system, and always meaningful when employed properly.

Scott
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution