[swift-evolution] Typealiases in protocols and protocol extensions

[David Hart]

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.wu at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160509/97fb308c/attachment.html>