<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On Sep 29, 2016, at 7:45 PM, Jonathan Hull <<a href="mailto:jhull@gbis.com">jhull@gbis.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">+1 to conditional conformances in general.</div><div class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">>><i class=""> 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>><i class="">
</i>><i class=""> 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.
</i>
Yeah your description is already sounding like a lot of work :)</pre></blockquote><div class="">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.</div></div></div></blockquote><div><br></div>I agree that we need to address the inability to disambiguate in the language. I'd like to see it addressed comprehensively, so we don't end up with one syntax in part of the language that doesn't work in another, similar part of the language. So it should cover "I want to call this specific thing in this protocol extension defined in this other module..." and "I want to this method to implement that requirement of this specific protocol" and such. <div><br></div><div>In a sense, this particular proposal doesn't "need" disambiguation because it bans ambiguities. <br><div><br><blockquote type="cite"><div><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class=""><i class="">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.
</i>
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.</pre></blockquote><div class=""><br class=""></div><div class="">I agree with David that the non-overlapping issue is going to come up a lot around things like Equatable.</div></div></div></blockquote><div><br></div>Yeah, it's likely to happen most with libraries imported from C/Objective-C and the standard library's protocols, because the C/Objective-C types won't have considered those conformances initially and yet everyone uses the standard library protocols. </div><div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div><br></div>This is roughly the shape of solutions we've discussed. There is some runtime validation we might need---for example, to make sure all of the conformances define the same associated type witnesses---but it's something we can probably do via lazy deduplication at runtime. </div><div><br></div><div> - Doug</div><div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div></div></blockquote></div></div></body></html>