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
