[swift-evolution] [Discussion] Generic protocols

Adrian Zubarev adrian.zubarev at devandartist.com
Sat Dec 3 08:22:55 CST 2016


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 (daniel at crossroadlabs.xyz) 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 <swift-evolution at swift.org> 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 (hello at andersio.co) 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 <swift-evolution at swift.org> wrote:

On Dec 2, 2016, at 12:34 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> 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
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161203/aff2a2e9/attachment.html>


More information about the swift-evolution mailing list