[swift-evolution] Introduce "associated_type" keyword
Loïc Lecrenier
loiclecrenier at icloud.com
Sun Dec 6 09:32:05 CST 2015
Well, I went ahead and created a pull request :)
I also included a “proposed approach” section, where I propose to deprecate
the `typealias` keyword for Swift 2.2, and replace it entirely for Swift 3.0.
Does anyone have any thought on that? This is a bit aggressive, but I think it’s worth it.
It is actually the same approach Erica proposed for removing C for-loops.
Loïc
> On Dec 6, 2015, at 1:12 PM, Loïc Lecrenier <loiclecrenier at icloud.com> wrote:
>
> I have drafted a formal proposal here: https://gist.github.com/loiclec/22459d230a21dbcb81fc
> Would love to receive feedback from the community on it, I am particularly worried about the correctness of the terms I used.
> Should I make a pull request to swift-evolution now, or should we continue the conversation here?
>
> Thanks,
>
> Loïc
>
> (and sorry about emailing you on Sunday 😇 )
>
>> On Dec 6, 2015, at 1:48 AM, John McCall <rjmccall at apple.com> wrote:
>>
>>> On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution at swift.org> wrote:
>>> Hi everyone :)
>>>
>>> I propose introducing a new "associated_type" keyword that will replace "typealias" for declaring associated types in protocols.
>>> I remember being confused by associated types when I started using Swift, and I think one reason why was the use of the typealias keyword to define them.
>>> One reason was that I thought I knew what typealias did, and so I didn't stop to learn what it did inside a protocol. An other reason was the difficulty of finding help when searching for "typealias" instead of "associated types".
>>> Then, when I thought I understood it, I started building an excessively protocol-oriented program as an exercise. And I still lost a lot of time fighting Swift by trying to use "real" typealias-es inside of protocols.
>>>
>>> Conceptually, I had something like this:
>>>
>>> protocol ProtA {
>>> typealias Container : SequenceType
>>> }
>>> protocol ProtB {
>>> typealias AnOtherAssocType : ProtA
>>> func foo(x: AnOtherAssocType.Container.Generator.Element, y: AnOtherAssocType.Container.Generator.Element) -> AnOtherAssocType.Container.Generator.Element
>>> }
>>>
>>> The function foo is very difficult to read, so I wanted to use a shortcut to Element by doing this:
>>>
>>> protocol ProtB {
>>> typealias A : ProtA
>>> typealias Element = A.Container.Generator.Element
>>> func foo(x: Element, y: Element) -> Element
>>> }
>>>
>>> But by doing so, I didn't create a shortcut to Element, but an associated type with a default value of Element. (right?)
>>> Then I tried to write extensions to ProtB where Element conforms to, say, Equatable, and couldn't make it work because A.Container.Generator.Element didn't conform to Equatable.
>>>
>>> So, that was a rather long explanation of the reasons I think we should replace the typealias keyword by associated_type, and allow "real" typealias-es inside protocols.
>>
>> I think this is a great idea; re-using typealias for associated types was a mistake.
>>
>> John.
>>
>>>
>>> Ideally, I would write
>>>
>>> protocol ProtB {
>>> associated_type AnOtherAssocType : ProtA
>>> typealias Element = AnOtherAssocType.Container.Generator.Element
>>> func foo(x: Element, y: Element) -> Element
>>> }
>>>
>>> and it would be exactly the same as
>>>
>>> protocol ProtB {
>>> associated_type AnOtherAssocType : ProtA
>>> func foo(x: A.Container.Generator.Element, y: A.Container.Generator.Element) -> A.Container.Generator.Element
>>> }
>>>
>>> There are probably some problems created by this proposal, but right now I can't see any :/
>>>
>>> Thanks,
>>>
>>> Loïc
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
More information about the swift-evolution
mailing list