I agree that this is counterintuitive behaviour and should ideally be changed
to match things like:
func f <T> (_: T.Type) {}
func f2 <T> (_: T.Type) {}
f(Int)
f2(String)
milos
> On 5 Apr 2016, at 17:16, Noah Blake via swift-evolution
> <[email protected]> wrote:
>
> Types associated with a protocol are not namespaced by the protocol, but
> rather by the protocol's adopters. As such, when two protocols declare a
> common associatedType, adoption of those protocols introduces undesirable
> ambiguity.
>
> Given the understandable propensity of developers to arrive at similarly
> named types (T, for example), it is likely that this problem will reduce the
> compatibility of packages for reasons that may not be entirely clear to the
> package consumer.
>
> Here is a demonstration of the issue. Apologies, I'm a longtime reader of the
> list, but this is my first time posting, and I'm not sure how best to format
> this. You may also find this example on Jira
> (https://bugs.swift.org/browse/SR-1065
> <https://bugs.swift.org/browse/SR-1065>).
>
> ```
> protocol A {
> associatedtype T
> var aT: T { get }
> }
>
> protocol B {
> associatedtype T
> var bT: T { get }
> }
> ```
>
> T is ambiguous: "Type C does not conform to protocol 'B'."
> ```
> class C: A, B {
> var aT = String()
> var bT = Int()
> }
> ```
>
>
> T is inferred unambiguously, compiles without error.
> ```
> class C: A, B {
> var aT = String()
> var bT = String()
> }
> ```
>
> T is explicit, but problematic: "Type C does not conform to protocol 'A'."
> ```
> class C: A, B {
> typealias T = Int
> var aT = String()
> var bT = Int()
> }
> ```
>
> I would greatly appreciate any advice or direction as to next steps. I have a
> proposal for resolving this in mind, but it seemed premature to offer it
> before finding some agreement that this was worth carrying forward.
>
> Best regards,
> Noah Blake
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
