[swift-evolution] [Proposal draft] Conditional conformances

[Jonathan Hull]

+1 to conditional conformances in general.
> >> What other designs were considered and rejected? It seems like some kind of escape hatch would be preferred if you happen to get into this situation, though you make some really good points about the pitfalls.
> > 
> > I don’t have a fully-baked alternative proposal—it would probably have to involve some kind of preference rule for picking the “best” set of (consistent!) conformances to satisfy a particular request, introduce a disambiguation syntax for cases where that preference rule does the wrong thing, and some way of teaching the dynamic-casting machinery to do the same thing.
> 
> Yeah your description is already sounding like a lot of work :)
I still think it is worth looking at this issue in general though. I think it is one of the big holes in swift’s grammar, and the sooner we find a way to express distributed ordering, the less churn it will cause when we make the change (and the more consistency we can have across language features which share this issue).  It doesn’t necessarily have to be fixed in this proposal though, as long as we don’t paint ourselves into a corner.

> You get a compile error if there are two conformances of SomeWrapper to Equatable; it doesn’t actually matter whether they are conditional, but people are far more likely to expect to be able to having overlapping conditional conformances.
> 
> Slightly off-topic but I was hit quick badly by this recently because two libraries I was trying to import both conformed UIControlState to Hashable to be able to use it as Dictionary indices. It seems like something that might happen kind of regularly with important protocols like Hashable and Equatable.

I agree with David that the non-overlapping issue is going to come up a lot around things like Equatable.

One potential solution would be to have the ability to mark a conditionally conforming extension as “weak” (or another term which has been bikeshedded).  In this case, it would then act similarly to default implementations of protocols.  That is, it would provide conformance if no one else was, but defer to any other implementation which is available. This means library authors can provide basic conditional conformance without locking out more specific implementations.  This deferral would likely be on a method by method basis (similar to default protocol implementations), though the “weak” (or equivalent) annotation would apply to the extension as a whole.

Thanks,
Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160929/126ef5db/attachment.html>