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

Anton Zhilin antonyzhilin at gmail.com
Mon Jul 4 08:33:06 CDT 2016


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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160704/4d39d97b/attachment.html>


More information about the swift-evolution mailing list