Yes, examples will be helpful.
On Fri, Jun 23, 2017 at 19:28 David Moore via swift-evolution < [email protected]> wrote: > I do indeed have quite a few real examples of this, such prompted me to > bring this up. I think this could be done without any impact to existing > code, but it would require some type of keyword. Take the following as a > possible prototype. > > protocol Foo { > associatedtype T > } > > struct Bar<T> : Foo { > keyword typealias T // Or really any other syntactical implementation. > } > > With an opt-in method we could implement this without affecting existing > code, thereby making this more viable. I will send some examples later. > > On Jun 23, 2017, at 6:52 PM, Xiaodi Wu <[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]> 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] >> 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
