[swift-evolution] Typealiases in protocols and protocol extensions

Mon May 9 03:05:23 CDT 2016

On Mon, May 9, 2016 at 2:33 AM, David Hart <david at hartbit.com> wrote:

>
> On 09 May 2016, at 09:30, Xiaodi Wu <xiaodi.wu at 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?
>

Nothing's coming to mind right off the bat. Perhaps the writer of the
Manifesto could chime in...

On Mon, May 9, 2016 at 02:24 David Hart <david at hartbit.com> wrote:
>
>> On 09 May 2016, at 08:53, Xiaodi Wu <xiaodi.wu at 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.wu at 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 <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/01b0a268/attachment-0001.html>