[swift-evolution] [Pitch] Remove type inference for associated types

[David Hart]

I don't see that as confusing. In a conforming type, he compiler is looking for a type with the same name as the associatedtype declaration. As the proposal mentions, typealias is not the only way to provide that type. It's actually logical to typealias to point the compiler to the correct type as well as it is to define a internal type with the same name from the start.

> On 30 Jun 2016, at 15:22, Brandon Knope via swift-evolution <swift-evolution at swift.org> wrote:
> 
> But surely using two different keywords could seem confusing to many as part of the same system?
> 
> Using associatedtype in the declaration and then typealias in the conforming type just seems inconsistent and ripe for confusion. '
> 
> I am curious if any advanced Swift users still get tripped up here
> 
> Brandon 
> 
> Sent from my iPad
> 
> On Jun 30, 2016, at 8:53 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>>> On Jun 29, 2016, at 6:55 AM, Brandon Knope via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> What's the rationale for having associatedtype in protocols and typealias in the conforming types?
>> 
>> I didn't design it, but here's how I think about it: The associated type requirement merely states that there must be a type with this name meeting these criteria. `typealias` is one way to satisfy that requirement, but you can also just define a nested type with that name:
>> 
>>   struct MyCollection {
>>       struct Index: Comparable { … }
>>   }
>> 
>> Should you replace `struct` with `associatedtype`? No? Then why would you replace `typealias` with `associatedtype`?
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution