> On Jun 27, 2017, at 12:39 PM, Jaden Geller via swift-evolution > <[email protected]> wrote: > > 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.
I agree. I have run into this as well and have been frustrated by it. It isn’t clear to me what the best solution is but I’d love to see one that could make it into a 4.x release. > > Cheers, > Jaden Geller > >> On Jun 23, 2017, at 3:52 PM, Xiaodi Wu via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
