[swift-evolution] [Discussion] Generic protocols

[Adrian Zubarev]

I’m fine with adding features step by step. ;)

There is no need for an explicit type alias in your

extension MyStruct : Constructible<String> { … }
Because Value is already constrained by String.

2. Should have it’s own thread because the problem already exists today and is not yet formally solved.

protocol A { var test: Int { get set } }
protocol B { var test: Int { get set } }

struct C : A, B {  
    // fine, but maybe there might be two different `test` properties
    var test: Int = 42  
     
    // vs. (if there is that what was intended by `A` and `B`)
    var A.test: Int = 0
    var B.test: Int = 1
}  
In my typealias examples I mixed 1. and 4. together.

protocol GenericFoo<T> : Foo where Value == T { /* nothing here */ }

typealias GenericFoo<T> = Foo where Value == T
I see that the latter cannot produce an actual new protocol, because it’s more like a macro and cannot be used multiple times for conformances.

struct D : GenericFoo<Int>, GenericFoo<String> {}

// vs.
struct D : Foo where Value == Int, /* cannot add the second macro for String */ {}
And that is probably why we need real parametrized protocols.

That said, I’m fine starting with 1. and really looking forward to the talk about 4.

Questions about 1.:

Does it affect ABI or is it needed to simplify the stdlib somehow?
Is it something for the current phase?


-- 
Adrian Zubarev
Sent with Airmail

Am 10. Dezember 2016 um 11:31:09, Anton Zhilin (antonyzhilin at gmail.com) schrieb:

I have to agree with Tino Heth, our aim is to add something basic at first. Although we’d better make sure that we will be able to add other wanted features in the future.

How about this plan?

Generic protocols without associated types
Basic conflict resolution using “dot” syntax
Generic protocols with associated types (depends on (2))
Specialization of non-generic protocols with associated types (+work on existential notation)
Some inline reply follows.

While trying to find the talk about overlapping protocol members from different protocols I spotted your proposal: https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/NNNN-generic-protocols.md

This is quite an old listing. Thanks for reminding!

Here is the evolution-thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20160919/027122.html

The suggestion there was to prefix everything with the corresponding protocol when there is a collision.

struct Test : Foo<Int>, Foo<String> {
    init(_ value: Foo<Int>.Value) { … }    // or better: init(_ value: Int)
    init(_ value: Foo<String>.Value) { … } // init(_ value: String)
      
    // assume both had the function `foo()`
    func Foo<Int>.foo() { … }
    func Foo<String>.foo() { … }
}
That’s a working solution. It doesn’t scale very much, if we try to apply it to protocol inheritance (conformance) hierarchies, but we shouldn’t care for now.

Is there really a need for true generic protocols? I’m still fascinated by the idea how a generic and constrained typealias could create this new ‘pseudo’ generic protocol.
I agree that ideally, existing protocols should be intact. If so, then we should consider “the original protocol with associated types” and “explicitly specialized protocol” as two different protocols:

protocol Constructible {
    associatedtype Value
    func foo()
}

struct MyStruct : Constructible {
    typealias Value = Int
    func foo() { }
}

extension MyStruct : Constructible<String> {  // or Constructible<Value: String>, or whatever
    typealias Constructible<String>.Value = String
    func Constructible<String>.foo() { }
}

MyStruct.Value  // Int
MyStruct.Constructible<String>.Value  // String

func bar<T: Constructible>(t: T)  // can call with MyStruct
func bar<T: Constructible<Int>>(t: T)  // can NOT call with MyStruct
func bar<T: Constructible<String>>(t: T)  // can call with MyStruct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161210/b8a0fb23/attachment.html>