Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

There's been a little movement on this in the ticket that I opened. Joe Groff suggested the following attribute: @implements(A.T) typealias AT = String @implements(B.T) typealias BT = Int I would prefer a syntax more in line with what you suggested typealias A.T = String typealias B.T = Int

Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

Apologies - in /stdlib proper, there are only 207 usages of "", and no occurrences of "associatedtype T." My previous figures come from a grep of the entire repo. On Wed, Apr 6, 2016 at 6:19 AM, Noah Blake wrote: > I don't think there's much of a point solving this just for

Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

> > I don't think there's much of a point solving this just for associated > types. The same issue exists for all protocol requirements. True enough. The one difference worth noting, however, is that there's no way to address the ambiguity of identical protocol requirements without adding

[swift-evolution] [Pitch] Add namespacing to associatedTypes

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