I think I might found a solution that will satisfy generic protocols and not
break the system.
The generics manifesto shows two features that are requested from generic
protocols.
The first feature is needed to reuse the same protocol multiple types like
struct A : Proto<B>, Proto<C>.
With SE–0142 we can actually achieve this behavior by creating new protocols
and set a subset of the associated types from its parent super protocol.
Now we can use this trick to solve the problem from above and create two new
protocols and use them as we previously wanted struct A : ProtoB, ProtoC. While
this is great and solves my issue I’d like to pitch a shortcut for this.
Protocols with associated types are kinda generic, but they still need SE–0142
to specify all the associated types.
How about making all protocols that contain associated types to also have a
shortcut generic protocol that specifies all the associated type in its generic
parameter list?
Some first bikeshedding:
protocol MyStringCollection : Collecntion where Iterator.Element == String,
Index == Int {}
protocol Collection<ElementType, IndexType> : Collection {
typealias Iterator.Element = ElementType
typealias Index = IndexType
}
But instead of creating these types by yourself, the compiler would
autogenerate these for any protocol that have a list of associated types. To
prevent collision between protocol names like Collection vs.
Collection<ParamList> one could automatically prefix the generated procols with
Generic.
Collection will generate GenericCollection<Element, Index>
This would be a huge shortcut for the feature introduced in SE–0142.
What does the community think about this idea?
--
Adrian Zubarev
Sent with Airmail
Am 2. Dezember 2016 um 20:13:50, Charles Srstka ([email protected])
schrieb:
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
