Syntactic sugar could only solve the first issue because it would create a
generic type that allows you to reuse your protocol with associated types in a
way like ConstructibleFromValue<Float> would.
The idea is simple, but there are a few disadvantages that makes it less worth
to implement.
If I should describe it in a different way, I’d prefer something like this
instead:
typealias GenericCollection<E> = Collection where Iterator.Index == Int,
Element == E
//====================================//
protocol ConstructibleFromValue {
associatedtype ValueType
init(_ value: ValueType)
}
typealias ConstructibleFrom<V> = ConstructibleFromValue where ValueType == V
// In both cases I want to be able to conform to this macro/shortcut.
// I don't speak about existentials here.
protocol MyType {}
extension MyType : ConstructibleFrom<Float> {
init(_ value: Float) { ... }
}
extension MyType : ConstructibleFrom<Double> {
init(_ value: Double) { ... }
}
--
Adrian Zubarev
Sent with Airmail
Am 3. Dezember 2016 um 21:21:23, Xiaodi Wu ([email protected]) schrieb:
I'm not sure I understand. The first feature in the generics manifesto is
parameterized protocols so that you can have, say, ConstructibleFrom<Float> and
ConstructibleFrom<Int> and the ability to conform to the same protocol in two
ways. The second feature is explained as a request for generalized
existentials. I don't understand how syntactic sugar solves either issue.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
