[swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu]

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> 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
> 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/e6ba77f1/attachment.html>