[swift-evolution] [Discussion] Generic protocols

[Daniel Leping]

Love it. I have one concern, though. How do we resolve conflicting
associated types once several protocols get applied to a class or a struct?

On Sat, 3 Dec 2016 at 11:00 Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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 (cocoadev at charlessoft.com)
> schrieb:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161203/94309e32/attachment.html>