Ok. Let's say I have a generic protocol P<T> with two methods: func foo() func bar(o:T)
I have a default implementation of foo, which internally calls bar. How would work foo once a class implements P<Int> and P<String>? On Sat, 3 Dec 2016 at 15:26 Adrian Zubarev via swift-evolution < [email protected]> wrote: > I believe generic protocols could be used as a shortcut for protocols with > associated types. > > // Protocol with associated type > > protocol Foo { > > associatedtype F > func foo(_ f: F) > } > > // Existential > typealias IntFoo = Any<Foo> where F == Int > > struct Test : IntFoo {} // error > > struct Test : Foo { func foo(_: Int) {…} } > > let intFoo: IntFoo = Test() // fine > > // SE-0142 > > protocol IntFooProtocol : Foo where F == Int {} > > // Generic protocols > // Autogenerated with all associated types present in the parameter list > > protocol GenericFoo<F> : Foo { … } > > Instead of creating new protocol for a different subset of types > constrained by the where clause, this approach could come really handy. > > Does it affect stdlib and/or ABI somehow? When SE–0142 is implemented to > improve the stdlib, wouldn’t that mean that more types like IntFooProtocol > from above will spawn? > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 3. Dezember 2016 um 13:47:13, Anders Ha ([email protected]) schrieb: > > This is called generalized existentials. It is included in the Generic > Manifesto, has been discussed quite a few times with long email chains > before, and spawned the change to the `protocol<>` syntax as kinda a > precursor. It would be surprised if Swift 4 Phase 2 doesn't have it given > its popularity. > > Regards > Anders > > On 2 Dec 2016, at 20:13, Charles Srstka via swift-evolution < > [email protected]> wrote: > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
