This is a different problem that protocols have today. There was some talk
about having some sort of keyword like implements to disambiguate which from
where the implementation comes from.
Just pretend for a second, we wouldn’t have generic protocols and implement it
the SE–01242 way:
protocol Foo {
associatedtype T
func foo()
func bar(o: T)
}
protocol IntFoo : Foo where T == Int {}
protocol StringFoo : Foo where T == String {}
// Where do you want your extension?
extension Foo {
func foo() {
// cannot call bar from here, we don't know what T is
}
}
extension Foo where T == String {
func foo() {
self.bar(o: "works fine") // calls a function that accepts a String
}
}
extension Foo where T == Int {
func foo() {
self.bar(o: 42) // calls a function that accepts an Int
}
}
class MyClass : IntFoo, StringFoo {
// implement bar for Int and String
// foo is problematic here already, and we haven't talked about generic
protocols yet
}
See it’s not the problem of the generic protocols but the overlapping function
foo of different protocols IntFoo and StringFoo.
In general Foo<T> would have the same problem. It should be solved in a
different way, which is not part of this pitch.
--
Adrian Zubarev
Sent with Airmail
Am 3. Dezember 2016 um 15:07:03, Daniel Leping ([email protected])
schrieb:
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
