> On 09 May 2016, at 08:53, Xiaodi Wu <[email protected]> wrote: > > And to clarify, FWIW, I think it'd be wonderful to implement this feature, > and I share your sense that sometimes conversations on this list get a little > sidetracked. My comments are not meant to suggest that this is not a good > feature; rather, they go to your question to the list--does your proposal > need any modifications before a PR? > > IMO, some sections need to be fleshed out. Some discussion on how your > proposed rules interact with other aspects of the language when they are used > in the daily task of conforming types to protocols is called for. I accept > your point that perhaps it doesn't belong in the 'Impact on Existing Code' > section.
I’ll add something. > I hope you'll forgive me for saying that the proposal seems, overall, hastily > written. That there are two misspelled instances of "typealias" in a proposal > about typealias does not give one confidence that what is proposed has been > sufficiently considered. I don’t mind you saying it, it is a very early draft. That’s why I’m putting it in front of the community before sending it for a Pull Request. > On Mon, May 9, 2016 at 01:06 Xiaodi Wu <[email protected] > <mailto:[email protected]>> wrote: > 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] > <mailto:[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] >> <mailto:[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
