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 ([email protected]) 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
