[swift-evolution] Introduce "associated_type" keyword

[Kevin Lundberg]

Is it possible to do away with associated types and just use plain generic type declarations instead? This is one thing that kind of confuses me about the generics system. Coming from Java and c#, interfaces there are generic in the same way that classes (and structs in c#) are, and there are a lot of nice things we could get along with that if protocols were generic as part of their type declaration. Is there a compelling (technical or otherwise) reason to keep associated types as they are (to the exclusion of generic parameters) today that I'm missing?

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"
--
Kevin Lundberg

On Dec 5, 2015, at 7:48 PM, John McCall via swift-evolution <swift-evolution at swift.org> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution