> * 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
