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

[Noah Blake]

>
> 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 <brent at architechies.com>
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160406/30974b7a/attachment.html>