<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="" applecontenteditable="true">Hi, everyone. I wanted to get some advice on an issue I've been worrying about: the effect of added conformances on source compatibility. Let's take my own (stale) PR as an example: <a href="https://github.com/apple/swift/pull/4568" class="">#4568</a> makes all CF types Equatable and Hashable, using the functions CFHash and CFEqual. What happens if somebody's already done that in their own extension of, say, <a href="https://developer.apple.com/reference/corefoundation/cfbag-s1l#//apple_ref/swift/cl/c:@T@CFBagRef" class="">CFBag</a>?<div class=""><br class=""></div><div class="">(Let's <i class="">not</i> debate in this thread whether this is a good idea. It's consistent with NSObject, at least.)</div><div class=""><br class=""></div><div class="">Since conformances are globally unique today, I <i class="">think</i> the only valid short-term answer is to say the user's conformance is invalid, and indeed that's the behavior you would get today if you update to a newer version of a package and discover that they've added a conformance.</div><div class=""><br class=""></div><div class="">The trouble is that this breaks Swift 3 source compatibility. Unlike many other changes, conformances cannot be made conditional on the language version. This isn't just because of syntax; someone may have a generic type that relies on the conformance being present, and it would be an error to construct that type without the conformance.</div><div class=""><br class=""></div><div class="">The solution I thought of was to downgrade the error to a warning, saying "this conformance is invalid <i class="">and will be ignored".</i> This isn't ideal, but it will <i class="">probably</i> do the right thing—how often is there a protocol you can add to a type in multiple, significantly different ways?</div><div class=""><br class=""></div><div class="">Okay, great. Except this only solves half the problem: in order to implement Hashable, I need to provide a 'hashValue' property. We normally don't treat API additions as breaking changes because that would keep us from making <i class="">any</i> changes, but protocol requirements are a little different—in those cases we are clearly going to have naming conflicts. These, of course, are reported as errors today, and it feels much stranger to downgrade <i class="">those</i> errors to warnings. "Sorry, this code you have written is going to be ignored, but we'll keep building anyway?" Seems very fishy.</div><div class=""><br class=""></div><div class="">Options (as I see them):</div><div class="">- Downgrade redeclaration errors to warnings for both conformances and members</div><div class="">- Downgrade conformance redeclaration errors to warnings, but leave member redeclaration as an error</div><div class="">- Just leave both of these as errors, and accept that this facet of source compatibility is imperfect, and anyone who needs to continue compiling with Swift 3.1 can add #if.</div><div class=""><i class=""><br class=""></i></div><div class="">Thoughts, answers? Thanks,</div><div class="">Jordan</div><div class=""><i class=""><br class=""></i></div><div class="">P.S. All of this will come back in spades with <a href="http://jrose-apple.github.io/swift-library-evolution" class="">library evolution</a>, and in particular there are <a href="http://jrose-apple.github.io/swift-library-evolution/#open-issues" class="">open issues</a> in the document around this.</div><div class=""><br class=""></div><div class="">P.P.S. Thanks to Dave Abrahams and Huon Wilson for initial discussion on this.</div></body></html>