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] <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
