[swift-evolution] [Pitch] Achieving a heterogeneous collection of Equatables

[Roopesh Chander S]

On Tue, Dec 22, 2015 at 10:18 PM, Joe Groff <jgroff at apple.com> wrote:

> What you're proposing is closer to the other approach I laid out,
allowing protocol types to be
> extended to conform to protocols themselves

I couldn't find the thread you've explained this earlier, so I'm going by
what you've described in this thread.

> extension protocol<R>: P { // We're extending the protocol *type* to
conform, not its conformers
>   func f1(t: R) { }
> }

But we *do* want conformers of R to also conform to P (and have func f1's
implementation available in them, by virtue of conforming to R). If we
didn't, then if we apply this solution to the Swift stdlib, and we have the
following type hierarchy when we use it (considering the example from
http://inessential.com/2015/08/05/swift_diary_9_where_im_stuck):

protocol Equatable (in stdlib)
 -> protocol Hashable (in stdlib)
 -> protocol Account (in app)
     with a protocol extension:
     extension protocol<Account> : Equatable {
         func isEqual(lhs: Account, rhs: Account) -> Bool { return false }
     }
 -> class TwitterAccount (in app)

If I understand your solution correctly, the above setup means that the
Account protocol and the TwitterAccount class don't conform to Equatable -
only that the Account existential type conforms to Equatable. So we can't
do twitterUser1 == twitterUser2, and being able to do that is desirable for
this use case.

What I was proposing can be seen as a variation of your EquatesWith
approach, the difference being that the "where EquatesWith == Drawable"
part is automatically inferred by the compiler based on where the
super-protocol gets implemented in the type hierarchy. It could be
implemented in a class/struct, in which case `Subtype` would behave similar
to `Self`, or it could be implemented in a protocol, in which `Subtype`
would bind to the protocol (like, say, `Drawable`).

roop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/22b5e301/attachment.html>