I’ve run into this issue many times in the real world as well. For example,
consider the following protocol:
protocol OptionalType {
associatedtype Wrapped
}
It is not possible to conform `Optional` to this protocol because its generic
type is already named `Wrapped`. Only when the associated type can be inferred
is conformance possible.
I definitely think we need a solution, but I don’t know what that solution
should be.
Cheers,
Jaden Geller
> On Jun 23, 2017, at 3:52 PM, Xiaodi Wu via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> There could be source-breaking implications for such a feature, especially
> with retroactive conformance. Therefore, I think this could be very tricky
> and I'd want to be convinced that the benefits are very great to risk such a
> disturbance. Here, I think the problem is rather mild, and here's why:
>
> It is true that, in your example specifically, renaming T to U is the only
> solution (that I know of, anyway). However, for any "serious" protocol P,
> there's likely to be a required property of type P.T, or a function that
> takes an argument of type P.T or returns a value of type P.T. Therefore,
> implementing that requirement in Bar with a corresponding
> property/argument/return value of type Bar.T would generally do the trick.
>
> Have you got any real-world examples where you're running into this issue?
>
> On Fri, Jun 23, 2017 at 17:03 David Moore via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hello Swift Evolution,
>
> This may have already been discussed before, but I just came across a
> bothersome language aspect which reminded me to propose a solution.
> Currently, if we want to add generics to a protocol the only way to do so is
> with associated types. I am quite fine with the current approach with respect
> to those semantics.
>
> There is, however, a weakness that is built in with using associated types.
> That weakness is the lack of associated type and generic inference. To be
> more clear about what I mean, take the following as an example.
>
> protocol Foo {
> associatedtype T
> }
>
> The foregoing protocol is quite basic, but uses an associated type with the
> name “T.” Giving the associated type that name will illustrate the dilemma
> encountered later on down the pipeline.
>
> struct Bar<T> : Foo {
> // What am I supposed to do? The name is used for both the generic and
> the type alias Foo needs for conformance.
> typealias T = T // Error!
> }
>
> The above illustrates a situation where we want to connect the generic, which
> is supposedly named appropriately, and the protocol’s associated type. There
> is no elegant solution for this at the moment. All I could do is the
> following.
>
> struct Bar<U> : Foo {
> typealias T = U // Not nearly as readable.
> }
>
> Now, there may be a few ways to go about adding support for generic
> inference. The compiler as it is already does some awesome inference get when
> it comes to generics, so why not take it a step further? I propose the
> introduction of a keyword, or anything else that could work, to specify
> explicitly what a given type alias declaration would do when it comes to
> inferencing. Requiring a keyword would ensure source compatibility remains
> intact, and it would also make the code more readable.
>
> I don’t know if this would be something that people could find useful, but I
> surely would. The implicit mapping of an associated type and a given generic
> by their names, would be a natural development.
>
> Let me know if this is just useless, or if could be a potential feature.
>
> Thank you,
> David Moore
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
