[swift-evolution] Typealiases in protocols and protocol extensions

Mon May 9 02:33:52 CDT 2016

> 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?

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