<div dir="ltr">Apologies - in /stdlib proper, there are only 207 usages of "<T>", and no occurrences of "associatedtype T." My previous figures come from a grep of the entire repo.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 6:19 AM, Noah Blake <span dir="ltr"><<a href="mailto:nononoah@gmail.com" target="_blank">nononoah@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">I don't think there's much of a point solving this just for associated types. The same issue exists for all protocol requirements.</span></blockquote><div><br></div></span><div>True enough. The one difference worth noting, however, is that there's no way to address the ambiguity of identical protocol requirements without adding syntactical overhead. In the case of associatedtype inferencing, however, it should be possible.</div><div><br></div><div><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><span style="font-size:12.8px">Then don't do that. Absurdly short associated/generic type names are like absurdly short variable or function names—they're okay in a very small context like a short function or a single loop, but a bad idea in a wider context. That's why the Swift 2 standard library moved away from using short names like `T` in generic types like Array and Optional.</span></span></blockquote></span><p><span>While this may be a bit orthogonal, it's worth noting that the standard library has increased its usage of T over the past month. Right now, it contains </span>3932 occurrences of <T>. Plenty of these usages are type-scoped. To your point, there are only 46 occurrences of "associatedtype T".</p><p>Regardless, there are plenty of longer, arguably better associatedtype names that writers of different packages may commonly reach for. "Element" may be known to be somewhat off limits, but it is representative of this category.</p></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 6, 2016 at 1:45 AM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> 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.<br>
<br>
</span>I don't think there's much of a point solving this just for associated types. The same issue exists for all protocol requirements.<br>
<span><br>
> 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.<br>
<br>
</span>Then don't do that. Absurdly short associated/generic type names are like absurdly short variable or function names—they're okay in a very small context like a short function or a single loop, but a bad idea in a wider context. That's why the Swift 2 standard library moved away from using short names like `T` in generic types like Array and Optional.<br>
<span><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>