<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I agree with Brent that there is a larger issue to solve, but I would still like to hear your solution, as it may inform the larger solution (and this may be a starting point to tackling the whole thing).</div><div class=""><br class=""></div><div class="">The thing that makes the most sense to me, off the top of my head, is to have an error that says: “T is ambiguous: Use A.T or B.T to disambiguate.”. It should actually list out the cases if that is technically possible. I could also see the argument that you should always have to specify the protocol (i.e. ‘A.T' instead of just ’T’) since that would solve post-hoc naming collisions. I would also be ok with inferring which protocol T belongs to when it is unambiguously possible.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The larger issue is what if protocols A & B both have ‘var t:T’. The interaction of these two problems needs to be considered before we can make traction on either.</div><div class=""><br class=""></div><div class="">It seems to me there are two cases for ‘var t:T’: either the T’s are the same or they are different. If they are the same, then everything is ok assuming the semantics are also the same, but that is a big assumption. If the T's are different, compliance would require overloading a property, which isn’t currently allowed in Swift. I think there was a proposal to have something like ‘var t:T implements A’ and then having the caller disambiguate at the call site using ‘(x as A).t’.</div><div class=""><br class=""></div><div class="">It starts to get complex very quickly… (but it is still design work that we have to do at some point)</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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 (
<a href="https://bugs.swift.org/browse/SR-1065" class="">https://bugs.swift.org/browse/SR-1065</a>).
```
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</pre></blockquote><div class=""><br class=""></div></body></html>