> On Sep 28, 2016, at 5:53 PM, Douglas Gregor <dgre...@apple.com> wrote: > > >> On Sep 28, 2016, at 1:28 PM, plx via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> It’s good to see this starting to happen! >> >> Is the decision on "no-overlapping-conformances” something that’s seen-as >> set in stone permanently, set in stone for the near future, or perhaps at >> least somewhat open to reconsideration at the present moment? > > There hasn’t been a decision per se, so it that sense it’s open to > reconsideration.
I see. A related question: if overlapping conditional conformances are disallowed in Swift 4, would e.g. ABI concerns make it infeasible to relax that restriction in future Swift (5, 6, X, etc.)? FWIW my overall 2c is that the right move right now is to leave out overlapping conformances due to the complexity…as long as doing so now doesn’t realistically mean never being able to relax that restriction at some later date. I realize it’s always *possible* to relax it, so to try and be even clearer I really mean “possible to relax it without having to compromise on things like ABI-stability (etc.)”. Also FWIW my suspicion is that in the absence of overlapping conformances some real pain points will be discovered—and those points *could* be addressed via overlapping conformances—but I also suspect that the majority of these pain points will also be addressable via some simpler mechanism (a constrained form of overlapping, macros, easy wrapper synthesis, etc.). Thus I’m in favor of banning conditional conformances for now unless doing so now would be the same as doing so “forever”, so to speak. > I have a strong *personal* bias against overlapping conformances, because I > feel that the amount of complexity that they introduce into the language and > its implementation far outweigh any benefits. Additionally, they enable use > cases (e.g., static metaprogramming-ish tricks) that I feel would be actively > harmful to the Swift language’s understandability. Generics systems can get > very complicated very quickly, so any extension needs to be strongly > motivated by use cases to matter to all or most Swift developers. This is purely anecdotal but I had a lot of utility code laying around that I’d marked with notes like `// TODO: revisit once conditional conformances are available`. When I was leaving those notes I was expecting to need overlapping conformances often, but I reviewed them *before* replying and I actually haven’t found an example where having overlapping conformances is both (1) a significant win and also (2) a win in a way that’d be of broad, general interest. - 80% have no real need for overlapping conditional conformances - 15% might have “elegance gains” but nothing practically-significant - 5% would *probably* see real gains but are likely not of broad interest …which wasn’t what I was expecting, but leaves me a lot more comfortable without overlapping conformances for now than I was in the abstract. > > - Doug > >> >>> On Sep 26, 2016, at 7:18 PM, Douglas Gregor via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> Conditional conformances >>> >>> Proposal: SE-NNNN >>> <https://github.com/DougGregor/swift-evolution/blob/conditional-conformances/proposals/NNNN-conditional-conformances.md> >>> Author: Doug Gregor <https://github.com/DougGregor> >>> Review Manager: TBD >>> Status: Awaiting review >>> During the review process, add the following fields as needed: >>> >>> Decision Notes: Rationale >>> <https://lists.swift.org/pipermail/swift-evolution/>, Additional Commentary >>> <https://lists.swift.org/pipermail/swift-evolution/> >>> Bugs: SR-NNNN <https://bugs.swift.org/browse/SR-NNNN>, SR-MMMM >>> <https://bugs.swift.org/browse/SR-MMMM> >>> Previous Revision: 1 >>> <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md> >>> Previous Proposal: SE-XXXX >>> <https://github.com/DougGregor/swift-evolution/blob/conditional-conformances/proposals/XXXX-filename.md> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#introduction>Introduction >>> >>> Conditional conformances express the notion that a generic type will >>> conform to a particular protocol only when it's type arguments meet certain >>> requirements. For example, the Array collection can implement the Equatable >>> protocol only when its elements are themselves Equatable, which can be >>> expressed via the following conditional conformance on Equatable: >>> >>> extension Array: Equatable where Element: Equatable { >>> static func ==(lhs: Array<T>, rhs: Array<T>) -> Bool { ... } >>> } >>> This feature is part of the generics manifesto >>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-> >>> because it's something that fits naturally into the generics model and is >>> expected to have a high impact on the Swift standard library. >>> >>> Swift-evolution thread: TBD: Discussion thread topic for that proposal >>> <https://lists.swift.org/pipermail/swift-evolution/> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#motivation>Motivation >>> >>> Conditional conformances address a hole in the composability of the >>> generics system. Continuing the Array example from above, it's always been >>> the case that one could use the == operator on two arrays of Equatable >>> type, e.g., [Int]() == [Int]() would succeed. However, it doesn't compose: >>> arrays of arrays of Equatable types cannot be compared (e.g.,[Int] >>> <https://github.com/DougGregor/swift-evolution/blob/conditional-conformances/proposals>== >>> [Int] >>> <https://github.com/DougGregor/swift-evolution/blob/conditional-conformances/proposals>will >>> fail to compile) because, even though there is an==for arrays of >>> Equatabletype, the arrays themselves are neverEquatable`. >>> >>> Conditional conformances are particularly powerful when building generic >>> adapter types, which are intended to reflect the capabilities of their type >>> arguments. For example, consider the "lazy" functionality of the Swift >>> standard library's collections: using the lazy member of a sequence >>> produces a lazy adapter that conforms to the Sequence protocol, while using >>> the lazy member of a collection produces a lazy adapter that conforms to >>> the Collection protocol. In Swift 3, the only way to model this is with >>> different types. For example, the Swift standard library has four similar >>> generic types to handle a lazy collection: LazySequence, LazyCollection, >>> LazyBidirectionalCollection, and LazyRandomAccessCollection. The Swift >>> standard library uses overloading of the lazy property to decide among >>> these: >>> >>> extension Sequence { >>> var lazy: LazySequence<Self> { ... } >>> } >>> >>> extension Collection { >>> var lazy: LazyCollection<Self> { ... } >>> } >>> >>> extension BidirectionalCollection { >>> var lazy: LazyBidirectionalCollection<Self> { ... } >>> } >>> >>> extension RandomAccessCollection { >>> var lazy: LazyRandomAccessCollection<Self> { ... } >>> } >>> This approach causes an enormous amount of repetition, and doesn't scale >>> well because each more-capable type has to re-implement (or somehow forward >>> the implementation of) all of the APIs of the less-capable versions. With >>> conditional conformances, one can provide a single generic wrapper type >>> whose basic requirements meet the lowest common denominator (e.g., >>> Sequence), but which scale their capabilities with their type argument >>> (e.g., the LazySequence conforms to Collection when the type argument does, >>> and so on). >>> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#proposed-solution>Proposed >>> solution >>> >>> In a nutshell, the proposed solution is to allow a constrained extension of >>> a struct, enum, or class to declare protocol conformances. No additional >>> syntax is necessary for this change, because it already exists in the >>> grammar; rather, this proposal removes the limitation that results in the >>> following error: >>> >>> t.swift:1:1: error: extension of type 'Array' with constraints cannot have >>> an inheritance clause >>> extension Array: Equatable where Element: Equatable { } >>> ^ ~~~~~~~~~ >>> Conditional conformances can only be used when the additional requirements >>> of the constrained extension are satisfied. For example, given the >>> aforementioned Array conformance to Equatable: >>> >>> func f<T: Equatable>(_: T) { ... } >>> >>> struct NotEquatable { } >>> >>> func test(a1: [Int], a2: [NotEquatable]) { >>> f(a1) // okay: [Int] conforms to Equatable because Int conforms to >>> Equatable >>> f(a2) // error: [NotEquatable] does not conform to Equatable because >>> NotEquatable has no conformance to Equatable >>> } >>> Conditional conformances also have a run-time aspect, because a dynamic >>> check for a protocol conformance might rely on the evaluation of the extra >>> requirements needed to successfully use a conditional conformance. For >>> example: >>> >>> protocol P { >>> func doSomething() >>> } >>> >>> struct S: P { >>> func doSomething() { print("S") } >>> } >>> >>> // Array conforms to P if it's element type conforms to P >>> extension Array: P where Element: P { >>> func doSomething() { >>> for value in self { >>> value.doSomething() >>> } >>> } >>> } >>> >>> // Dynamically query and use conformance to P. >>> func doSomethingIfP(_ value: Any) { >>> if let p = value as? P { >>> p.doSomething() >>> } else { >>> print("Not a P") >>> } >>> } >>> >>> doSomethingIfP([S(), S(), S()]) // prints "S" three times >>> doSomethingIfP([1, 2, 3]) // prints "Not a P" >>> The if-let in doSomethingIfP(_:) dynamically queries whether the type >>> stored in value conforms to the protocol P. In the case of an Array, that >>> conformance is conditional, which requires another dynamic lookup to >>> determine whether the element type conforms to P: in the first call to >>> doSomethingIfP(_:), the lookup finds the conformance of S to P. In the >>> second case, there is no conformance of Int to P, so the conditional >>> conformance cannot be used. The desire for this dynamic behavior motivates >>> some of the design decisions in this proposal. >>> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#detailed-design>Detailed >>> design >>> >>> Most of the semantics of conditional conformances are obvious. However, >>> there are a number of issues (mostly involving multiple conformances) that >>> require more in-depth design. >>> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#disallow-overlapping-conformances>Disallow >>> overlapping conformances >>> >>> With conditional conformances, it is possible to express that a given >>> generic type can conform to the same protocol in two different ways, >>> depending on the capabilities of its type arguments. For example: >>> >>> struct SomeWrapper<Wrapped> { >>> let wrapped: Wrapped >>> } >>> >>> protocol HasIdentity { >>> static func ===(lhs: Self, rhs: Self) -> Bool >>> } >>> >>> extension SomeWrapper: Equatable where Wrapped: Equatable { >>> static func ==(lhs: SomeWrapper<Wrapped>, rhs: SomeWrapper<Wrapper>) -> >>> Bool { >>> return lhs.wrapped == rhs.wrapped >>> } >>> } >>> >>> extension SomeWrapper: Equatable where Wrapped: HasIdentity { >>> static func ==(lhs: SomeWrapper<Wrapped>, rhs: SomeWrapper<Wrapper>) -> >>> Bool { >>> return lhs.wrapped === rhs.wrapped >>> } >>> } >>> Note that, for an arbitrary type T, there are four potential answers to the >>> question of whether SomeWrapper<T> conforms to Equatable: >>> >>> No, it does not conform because T is neither Equatable nor HasIdentity. >>> Yes, it conforms via the first extension of SomeWrapper because T conforms >>> to Equatable. >>> Yes, it conforms via the second extension of SomeWrapper because T conforms >>> to HasIdentity. >>> Ambiguity, because T conforms to both Equatable and HasIdentity. >>> It is due to the possibility of #4 occurring that we refer to the two >>> conditional conformances in the example as overlapping. There are designs >>> that would allow one to address the ambiguity, for example, by writing a >>> third conditional conformance that addresses #4: >>> >>> // Possible tie-breaker conformance >>> extension SomeWrapper: Equatable where Wrapped: Equatable & HasIdentity, { >>> static func ==(lhs: SomeWrapper<Wrapped>, rhs: SomeWrapper<Wrapper>) -> >>> Bool { >>> return lhs.wrapped == rhs.wrapped >>> } >>> } >>> The design is consistent, because this third conditional conformance is >>> more specialized the either of the first two conditional conformances, >>> meaning that its requirements are a strict superset of the requirements of >>> those two conditional conformances. However, there are a few downsides to >>> such a system: >>> >>> To address all possible ambiguities, one has to write a conditional >>> conformance for every plausible combination of overlapping requirements. To >>> statically resolve all ambiguities, one must also cover nonsensical >>> combinations where the two requirements are mutually exclusive (or invent a >>> way to state mutual-exclusivity). >>> It is no longer possible to uniquely say what is required to make a generic >>> type conform to a protocol, because there might be several unrelated >>> possibilities. This makes reasoning about the whole system more complex, >>> because it admits divergent interfaces for the same generic type based on >>> their type arguments. At its extreme, this invites the kind of cleverness >>> we've seen in the C++ community with template metaprogramming, which is >>> something Swift has sought to avoid. >>> All of the disambiguation machinery required at compile time (e.g., to >>> determine whether one conditional conformance is more specialized than >>> another to order them) also needs to implements in the run-time, as part of >>> the dynamic casting machinery. One must also address the possibility of >>> ambiguities occurring at run-time. This is both a sharp increase in the >>> complexity of the system and a potential run-time performance hazard. >>> For these reasons, this proposal bans overlapping conformances entirely. >>> While the resulting system is less flexible than one that allowed >>> overlapping conformances, the gain in simplicity in this >>> potentially-confusing area is well worth the cost. Moreover, this ban >>> follows with existing Swift rules regarding multiple conformances, which >>> prohibit the same type from conforming to the same protocol in two >>> different ways: >>> >>> protocol P { } >>> >>> struct S : P { } >>> extension S : P { } // error: S already conforms to P >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#implied-conditional-conformances>Implied >>> conditional conformances >>> >>> Stating conformance to a protocol implicitly states conformances to any of >>> the protocols that it inherits. This is the case in Swift today, although >>> most developers likely don't realize the rules it follows. For example: >>> >>> protocol P { } >>> protocol Q : P { } >>> protocol R : P { } >>> >>> struct X1 { } >>> struct X2 { } >>> struct X3 { } >>> >>> extension X1: Q { } // implies conformance to P >>> >>> extension X2: Q { } // would imply conformance to P, but... >>> extension X2: P { } // explicitly-stated conformance to P "wins" >>> >>> extension X3: Q { } // implies conformance to P >>> extension X3: R { } // also implies conformance to P >>> // one will "win"; which is unspecified >>> With conditional conformances, the question of which extension "wins" the >>> implied conformance begins to matter, because the extensions might have >>> different constraints on them. For example: >>> >>> struct X4<T> { } >>> >>> extension X4: Q where T: Q { } // implies conformance to P >>> extension X4: R where T: R { } // error: implies overlapping conformance >>> to P >>> Both of these constrained extensions imply a conformance to P, but the >>> actual P implied conformances to P are overlapping and, therefore, result >>> in an error. >>> >>> However, in cases where there is a reasonable ordering between the two >>> constrained extensions (i.e., one is more specialized than the other), the >>> less specialized constrained extension should "win" the implied >>> conformance. Continuing the example from above: >>> >>> protocol S: R { } >>> >>> struct X5<T> { } >>> >>> extension X5: R where T: R { } // "wins" implied conformance to P, because >>> extension X5: S where T: S { } // the extension where "T: S" is more >>> specialized >>> // than the one where "T: R" >>> Thus, the rule for placing implied conformances is to pick the least >>> specialized extension that implies the conformance. If there is more than >>> one such extension, then either: >>> >>> All such extensions are not constrained extensions (i.e., they have no >>> requirements beyond what the type requires), in which case Swift can >>> continue to choose arbitrarily among the extensions, or >>> All such extensions are constrained extensions, in which case the program >>> is ill-formed due to the ambiguity. The developer can explicitly specify >>> conformance to the protocol to disambiguate. >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#overloading-across-constrained-extensions>Overloading >>> across constrained extensions >>> >>> One particularly important aspect of the placement rule for implied >>> conformances is that it affects which declarations are used to satisfy a >>> particular requirement. For example: >>> >>> protocol P { >>> func f() >>> } >>> >>> protocol Q: P { } >>> protocol R: Q { } >>> >>> struct X1<T> { } >>> >>> extension X1: Q where T: Q { // note: implied conformance to P >>> here >>> func f() { >>> // #1: basic implementation of 'f()' >>> } >>> } >>> >>> extension X1: R where T: R { >>> func f() { >>> // #2: superfast implementation of f() using some knowledge of 'R' >>> } >>> } >>> >>> struct X2: R { >>> func f() { } >>> } >>> >>> (X1<X2>() as P).f() // calls #1, which was used to satisfy the requirement >>> for 'f' >>> X1<X2>().f() // calls #2, which is preferred by overload resolution >>> Effectively, when satisfying a protocol requirement, one can only choose >>> from members of the type that are guaranteed to available within the >>> extension with which the conformance is associated. In this case, the >>> conformance to P is placed on the first extension of X1, so the only f() >>> that can be considered is the f() within that extension: the f() in the >>> second extension won't necessarily always be available, because T may not >>> conform to R. Hence, the call that treats an X1<X2>as a P gets the first >>> implementation of X1.f(). When using the concrete type X1<X2>, where X2 >>> conforms to R, both X.f() implementations are visible... and the second is >>> more specialized. >>> >>> Technically, this issue is no different from surprises where (e.g.) a >>> member added to a concrete type in a different module won't affect an >>> existing protocol conformance. The existing ideas to mediate these >>> problems---warning for nearly-matching functions when they are declared in >>> concrete types, for example---will likely be sufficient to help surprised >>> users. That said, this proposal may increase the likelihood of such >>> problems showing up. >>> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#source-compatibility>Source >>> compatibility >>> >>> From the language perspective, conditional conformances are purely >>> additive. They introduce no new syntax, but instead provide semantics for >>> existing syntax---an extension that both declares a protocol conformance >>> and has a where clause---whose use currently results in a type checker >>> failure. That said, this is a feature that is expected to be widely adopted >>> within the Swift standard library, which may indirectly affect source >>> compatibility. >>> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#effect-on-abi-stability>Effect >>> on ABI Stability >>> >>> As noted above, there are a number of places where the standard library is >>> expected to adopt this feature, which fall into two classes: >>> >>> Improve composability: the example in the introduction >>> <https://github.com/DougGregor/swift-evolution/blob/conditional-conformances/proposals/Introduction> >>> made Array conform to Equatable when its element type does; there are many >>> places in the Swift standard library that could benefit from this form of >>> conditional conformance, particularly so that collections and other types >>> that contain values (e.g., Optional) can compose better with generic >>> algorithms. Most of these changes won't be ABI- or source-breaking, because >>> they're additive. >>> Eliminating repetition: the lazy wrappers described in the motivation >>> <https://github.com/DougGregor/swift-evolution/blob/conditional-conformances/proposals/motivation> >>> section could be collapsed into a single wrapper with several conditional >>> conformances. A similar refactoring could also be applied to the range >>> abstractions and slice types in the standard library, making the library >>> itself simpler and smaller. All of these changes are potentially >>> source-breaking and ABI-breaking, because they would remove types that >>> could be used in Swift 3 code. However, there are mitigations: generic >>> typealiases could provide source compatibility to Swift 3 clients, and the >>> ABI-breaking aspect is only relevant if conditional conformances and the >>> standard library changes they imply aren't part of Swift 4. >>> Aside from the standard library, conditional conformances have an impact on >>> the Swift runtime, which will require specific support to handle dynamic >>> casting. If that runtime support is not available once ABI stability has >>> been declared, then introducing conditional conformances in a later >>> language version either means the feature cannot be deployed backward or >>> that it would provide only more limited, static behavior when used on older >>> runtimes. Hence, there is significant motivation for doing this feature as >>> part of Swift 4. Even if we waited to introduce conditional conformances, >>> we would want to include a hook in the runtime to allow them to be >>> implemented later, to avoid future backward-compatibility issues. >>> >>> >>> <https://github.com/DougGregor/swift-evolution/tree/conditional-conformances#alternatives-considered>Alternatives >>> considered >>> >>> The most common request related to conditional conformances is to allow a >>> (constrained) protocol extension to declare conformance to a protocol. For >>> example: >>> >>> extension Collection: Equatable where Iterator.Element: Equatable { >>> static func ==(lhs: Self, rhs: Self) -> Bool { >>> // ... >>> } >>> } >>> This protocol extension will make any Collection of Equatable elements >>> Equatable, which is a powerful feature that could be put to good use. >>> Introducing conditional conformances for protocol extensions would >>> exacerbate the problem of overlapping conformances, because it would be >>> unreasonable to say that the existence of the above protocol extension >>> means that no type that conforms to Collection could declare its own >>> conformance to Equatable, conditional or otherwise. >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
