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.
On Wed, Apr 6, 2016 at 6:19 AM, Noah Blake <[email protected]> wrote: > 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 syntactical overhead. In the case of associatedtype inferencing, > however, it should be possible. > > 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. > > 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 3932 occurrences of <T>. Plenty of these usages are type-scoped. > To your point, there are only 46 occurrences of "associatedtype T". > > 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. > > On Wed, Apr 6, 2016 at 1:45 AM, Brent Royal-Gordon <[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. >> >> 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
