I see your point that nothing breaks in the stdlib with your proposal alone. It's undeniably true--by construction!--that a purely additive feature, if never used, will not cause problems.
That said, since the time that this feature was outlined in Doug's manifesto, I have been wondering how clashes such as the examples in my previous email are to be handled--i.e. what the rules of the language are to be--which I think is certainly germane to your proposal. Can a conforming type override a protocol typealias? Can a type conform to two protocols with conflicting typealiases if all requirements are otherwise satisfied? Surely, these merit discussion in your proposal. On Mon, May 9, 2016 at 12:48 AM David Hart <[email protected]> wrote: > Hello Xiaodi, > > What I mean by there is no impact on existing code is that the language > change has no impact. Of course, if the Standard Library then declares a > typealias Element in Sequence, it will clash with code which has declared > an Element typealias in sub-protocols, but that is separate from the > proposal. > > On 09 May 2016, at 07:28, Xiaodi Wu <[email protected]> wrote: > > If the protocol Sequence has typealias Element, does that mean I also have > MyConformingSequence.Element? > > If so, I think there is a potential impact on existing code not mentioned. > Suppose MyConformingSequence already (unwisely) declares typealias Element. > Now, what happens when I try to migrate my code to your proposed version of > Swift? > > This is a toy example, of course. More generally, though, I wonder about > this question: > > Suppose two protocols A and B each declare typealias Element. These > typealiases are, as you proposed, intended to simplify referencing indirect > associated types. But are they themselves considered protocol requirements? > > I ask because, suppose I want to conform type T to A and B. I implement > all the required methods and properties for such conformance. I declare the > appropriate typealiases for the associatedtypes declared in both protocols. > But, if A.Element and B.Element are incompatible with each other, it is > nonetheless impossible to conform T to both A and B? If it's forbidden, > isn't that kind of a bummer, since what's getting in the way is a naming > clash arising from a facility intended to simplify the naming of things > rather than provide for new functionality? If it's permitted, what is > T.Element? Some clarity here would be nice. > On Sun, May 8, 2016 at 6:17 PM David Hart via swift-evolution < > [email protected]> wrote: > >> Hello, >> >> I’ve come again with another proposal directly from the Generics >> Manifesto. Please let me know if it needs any modifications before sending >> the pull request. >> >> Typealiases in protocols and protocol extensions >> >> - Proposal: SE-XXXX >> >> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md> >> - Authors: David Hart <https://github.com/hartbit>, Doug Gregor >> <https://github.com/DougGregor> >> - Status: TBD >> - Review manager: TBD >> >> >> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#introduction> >> Introduction >> >> This proposal is from the Generics Manifesto >> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md> and >> brings the typealias keyword back into protocols for type aliasing. >> >> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#motivation> >> Motivation >> >> In Swift versions prior to 2.2, the typelias keyword was used outside of >> protocols to declare type aliases and in protocols to declare associated >> types. Since SE-0011 >> <https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md> >> and >> Swift 2.2, associated type now use the associatedtype keyword and >> typelias is available for implementing true associated type aliases. >> >> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#proposed-solution>Proposed >> solution >> >> The solution allows the creation of associated type aliases. Here is an >> example from the standard library: >> >> protocol Sequence { >> associatedtype Iterator : IteratorProtocol >> typealias Element = Iterator.Element >> } >> >> The example above shows how this simplifies referencing indirect >> associated types: >> >> func sum<T: Sequence where T.Element == Int>(sequence: T) -> Int { >> return sequence.reduce(0, combine: +) >> } >> >> >> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#detailed-design>Detailed >> design >> >> The following grammar rules needs to be added: >> >> *protocol-member-declaration* → *protocol-typealias-declaration* >> >> *protocol-typealias-declaration* → *typealias-declaration* >> >> <https://github.com/hartbit/swift-evolution/blob/typealiases-in-protocols/proposals/XXXX-typealiases-in-protocols.md#impact-on-existing-code>Impact >> on existing code >> This will have no impact on existing code, but will probably require >> improving the Fix-It that was created for migrating typealias to >> associatedtype in Swift 2.2. >> _______________________________________________ >> 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
