[swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu]

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 <david at 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.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> 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/07c98bb8/attachment.html>