[swift-evolution] Typealiases in protocols and protocol extensions

[Xiaodi Wu]

I agree with you that similar issues exist with the status quo. I'm not
asking that you fix them with your proposal, just that you document how
your proposed feature will work--i.e. please include some of this stuff you
just wrote here somewhere in the proposal text.

Your question to the list solicited suggestions for modifications to your
proposal. Mine is to flesh out "proposed solution" and/or "detailed
design." In "proposed solution," you describe how what you're proposing
would be useful based on a lone example. Elsewhere, under "motivation" you
write that you're proposing "true associated type aliases"--what, exactly,
is that? how does it interact with type aliases in conforming types and in
sub-protocols? can they be overridden? can they be masked like non-default
methods in protocol extensions are currently? I don't really have a beef
with the proposal whether the answers are yes or no, but I'd like to know
what the answers are by reading the proposal.

On Mon, May 9, 2016 at 01:52 David Hart <david at hartbit.com> wrote:

> I understand that name clashing in those instances is important to
> discuss, but I still think it is slightly orthogonal to the proposal. Let
> me try to explain why.
>
> If typealises in protocols are to have the same semantics as alises
> outside protocols (as I think they should), then they don’t change anything
> about the rules of collision. For example, the problem already exists today
> with associated types:
>
> protocol Foo {
>     associatedtype Inner: IntegerType
>     func foo(inner: Inner)
> }
>
> protocol Bar {
>     associatedtype Inner: FloatingPointType
>     var inner: Inner { get }
> }
>
> struct FooBarImpl: Foo, Bar { // error: Type ‘FooBarImpl’ does not conform
> to protocol ‘Bar'
>     func foo(inner: Int) {}
>     var inner: Float
> }
>
> Type aliasing would not change anything about the fact that those
> collisions already exists in the language and are not very well handled:
> either they are meant to be forbidden but in that case we need better
> diagnostics, or we want to have a way to work around them. Perhaps you’d
> like to start a discussion around fixing that ?
>
> On 09 May 2016, at 08: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/90493448/attachment.html>