Love it. I have one concern, though. How do we resolve conflicting associated types once several protocols get applied to a class or a struct?
On Sat, 3 Dec 2016 at 11:00 Adrian Zubarev via swift-evolution < [email protected]> wrote: > I think I might found a solution that will satisfy generic protocols and > not break the system. > > The generics manifesto shows two features that are requested from generic > protocols. > > The first feature is needed to reuse the same protocol multiple types like > struct > A : Proto<B>, Proto<C>. > > With SE–0142 we can actually achieve this behavior by creating new > protocols and set a subset of the associated types from its parent super > protocol. > > Now we can use this trick to solve the problem from above and create two > new protocols and use them as we previously wanted struct A : ProtoB, > ProtoC. While this is great and solves my issue I’d like to pitch a > shortcut for this. > > Protocols with associated types are kinda generic, but they still need > SE–0142 to specify all the associated types. > > How about making all protocols that contain associated types to also have > a shortcut generic protocol that specifies all the associated type in its > generic parameter list? > > Some first bikeshedding: > > protocol MyStringCollection : Collecntion where Iterator.Element == String, > Index == Int {} > > protocol Collection<ElementType, IndexType> : Collection { > > typealias Iterator.Element = ElementType > typealias Index = IndexType > } > > But instead of creating these types by yourself, the compiler would > autogenerate these for any protocol that have a list of associated types. > To prevent collision between protocol names like Collection vs. > Collection<ParamList> one could automatically prefix the generated > procols with Generic. > > Collection will generate GenericCollection<Element, Index> > > This would be a huge shortcut for the feature introduced in SE–0142. > > What does the community think about this idea? > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Dezember 2016 um 20:13:50, Charles Srstka ([email protected]) > schrieb: > > On Dec 2, 2016, at 12:34 PM, Adrian Zubarev via swift-evolution < > [email protected]> wrote: > > > I just overlooked that the subsection about generic protocols was inside > the *Unlikely* section. > > The problem is that I need a way to refer to a function with a specific > name. Plus the connection type has to have a specific API, like having a > DispatchQueue and know the router object if there is any (sounds like a > protocol right?!). The function reference should also keep the connection > object alive with a strong reference. > > associatedtype does not solve that problem for me. > > I clearly see that generic protocols overlap with associatedtype but > couldn’t we find a compromise here? For instance like Chris Lattner > introduced generic type aliases without the ability of constants. > > Why don’t we just use angle brackets to specify associated types? > Protocols aren’t using them for anything anyway. Then you could: > > if let someSequence as? Sequence<Iterator.Element == Int> { // do > something } > > which would form a nice parallel to the syntax for casting things to > generic types. > > Charles > > _______________________________________________ > 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
