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

Chris_Lattner · June 30, 2016, 6:26pm

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

Scott_James_Remnant · June 30, 2016, 6:43pm

-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

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

Erica_Sadun · June 30, 2016, 6:29pm

Just read through it.

I'd like to know more about how this proposal interacts with selector differentiation and overloading.

Thanks,

- E

···

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

https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

BigZaphod · June 30, 2016, 6:37pm

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

Taras_Zakharko1 · June 30, 2016, 7:14pm

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

* 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.

* 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

···

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

anandabits · July 1, 2016, 2:17am

* What is your evaluation of the proposal?

+1. When the review began I though I preferred something along the lines of the “prohibit implicit subtyping” alternative. However, I have followed the review thread closely and given deeper thought to the issue and I have become convinced that labels should not have a place in the Swift type system.

Labels often become nonsensical when disconnected from the root name of the function they originated in. It only makes sense for labels to be part of the type if the names of the labels are designed to stand alone.

However, this is rarely going to be the case. All functions and methods *must* have a root name. Argument labels are optional, and if supplied leverage the context provided by the root name.

Function parameters and properties withe function types that have labels still have an argument or property name (and possibly an external label name in the case of parameters). That name is at a distance from any labels in the function type but still provides context that programmers are likely to use (like it or not) when designing the names of the labels.

In all of the preceding cases the names in the type are heavily depending on the context of the declaration and do not really stand alone in a way that makes sense to include them as part of the type.

The only case I can think of where the labels are truly independent of something resembling a root name that could be used to call the function is in the case of a typealias:

typealias Predicate<T> = (value: T) -> Bool

(This is a bad example because you would not use a label here)

When you define a typealias like this there is no context providing additional meaning to the labels. In this case if you do allow them and include them in the type at least you don’t lose meaning and are likely to have labels that make some sense.

However, this is a narrow corner of the language. If this is the only place you can introduce labels without a high likelihood that they produce a type that has nonsense labels on its own (without the context in which the type was written) they are going to lead to far more confusion than they will provide value.

We should remove this feature for Swift 3. If this leads to less elegance or clarity in some use cases we should consider them carefully and see if a less fragile feature can be designed to support them.

* 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?

Absolutely. There are a lot of rough edges to this feature and we are removing rough edges in Swift 3.

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

Nothing similar enough to be worth mentioning.

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

In depth study.

···

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

Brad_Hilton · July 1, 2016, 2:37pm

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) -> ()```

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

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

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

Tony_Allevato · July 1, 2016, 11:36pm

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

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?

+1. I'm in agreement with others in this thread who say that the labels are
parts of the *name* of the function, not parts of its *type*. If I
understand the other discussions regarding the evolution of Swift's
function arguments model, the similarity to tuples with labeled components
is a historical artifact and now merely coincidental.

The analogy to Objective-C here is obvious, where you have selectors
instead of functions. The selector is the "name" of the "function" and it
contains all of the parts, not just the base name.

Swift function names to me are like German separable verbs. Even when
they're split across the sentence with multiple words in-between, the
prefix is still considered part of that verb, not a separate word/concept.

* 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?

Yes. This feels like a natural follow-up to SE-0021, which allowed the use
of argument names to differentiate between overloads with the same argument
types at the same positions. To me, this is another admission that the
labels are part of the function's *name*.

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

Aside from Objective-C mentioned above, the other languages I've used that
have named/keyword arguments (like Python) are dynamic languages that treat
the incoming argument list as a dictionary; in that case, the language
design is significantly different and I can't draw an analogy between them.

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

Read the proposal and loosely followed the discussion.

···

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

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

MutatingFunk · July 2, 2016, 3:02am

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.

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:

   https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

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.

···

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

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

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

pyrtsa · July 3, 2016, 8:36pm

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
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 <https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md>\.
    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 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md>\) 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 <https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#motivation>\. 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?

···

On 30 Jun 2016, Chris Lattner wrote:

Brent_Royal-Gordon · July 4, 2016, 11:17am

* 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

Tino · July 4, 2016, 6:50am

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.

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?

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

L_Mihalkovic · July 4, 2016, 6:04pm

An interesting take on arg label/name, granted this is including destructuring of obj literals (so one level down from the method sig, but which is not without analogy to what could be done to tuples with named fields). The main point of comparison is what the type of f1 and f2 are.

This is in typescript, where the signatures ultimately have to translate down to javascript where everything maps to
f(p,q,r,s,t) {
var p1 = arguments.0; // is p or this
...
}
last week i was back to writing lots of ts 1.8 code and i find the type system incredibly precise and flexible (P|Q... yeah)

// Type of f1 is (arg?: { x?: number, y?: number }) => void
function f1({ x = 0, y = 0 } = {}) { }

// And can be called as:
f1();
f1({});
f1({ x: 1 });
f1({ y: 1 });
f1({ x: 1, y: 1 });

// Type of f2 is (arg?: (x: number, y?: number) => void
function f2({ x, y = 0 } = { x: 0 }) { }
f2();
f2({}); // Error, x not optional
f2({ x: 1 });
f2({ y: 1 }); // Error, x not optional
f2({ x: 1, y: 1 });

Regards
(From mobile)

···

On Jun 30, 2016, at 8: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:

   https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

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

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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

Austin · June 30, 2016, 6:44pm

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> 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:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
> 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
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> 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

Austin · June 30, 2016, 6:50pm

-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)

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.

No they aren't, because of the implicit subtyping demonstrated above. It's
better to remove the significance of argument labels completely than to
vacillate on the topic and make promises we can't actually keep (per that
example).

···

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

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

xwu · June 30, 2016, 7:20pm

>
> 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:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
> * 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.

···

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:

> * 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

Michael_Ilseman · June 30, 2016, 10:33pm

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

···

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

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

xwu · June 30, 2016, 6:51pm

Austin, I agree with your point here that any sort of label should be
prohibited at the call site if your proposal is adopted; along those lines,
your suggested alternative of disallowing them in the type annotation might
win in terms of appropriately setting user expectations about labels
despite the loss in documentation.

···

On Thu, Jun 30, 2016 at 13:44 Austin Zheng via swift-evolution < 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> 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:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
> 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
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> 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

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

jrose · July 1, 2016, 2:36am

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md ]

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.)

I am in favor of this proposal.

Jordan

···

On Jun 30, 2016, at 11:44, Austin Zheng via swift-evolution <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:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
> 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
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Taras_Zakharko1 · June 30, 2016, 7:42pm

>
> 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:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
> * 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 :)

···

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 <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:

> * 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