> On Jul 4, 2016, at 1:36 PM, Vladimir.S via swift-evolution > <[email protected]> wrote: > > On 04.07.2016 14:17, Brent Royal-Gordon via swift-evolution wrote: >>> * 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 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
