> On 09 May 2016, at 09:30, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > Great, I hope this proposal finds much success with the community. > > One more thing: your title makes mention of protocol extensions, but protocol > extensions are mentioned nowhere else. Please include details on typealiases > in protocol extensions within the text or remove it altogether from the > proposal.
I left it in for now because it was explicitly mentioned in the Generics Manifesto (the title is a simple copy and paste), but I have yet to find good examples to illustrate their usefulness. Perhaps you could help me out on this one? > On Mon, May 9, 2016 at 02:24 David Hart <da...@hartbit.com > <mailto:da...@hartbit.com>> wrote: >> On 09 May 2016, at 08:53, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> 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 <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> 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 <da...@hartbit.com >> <mailto:da...@hartbit.com>> 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 <xiaodi...@gmail.com >>> <mailto:xiaodi...@gmail.com>> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> 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 https://lists.swift.org/mailman/listinfo/swift-evolution
