> > * 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
