> 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.
I don't think there's much of a point solving this just for associated types. The same issue exists for all protocol requirements. > 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. 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. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
