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: #4568 <https://github.com/apple/swift/pull/4568>
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, CFBag
<https://developer.apple.com/reference/corefoundation/cfbag-s1l#//apple_ref/swift/cl/c:@T@CFBagRef>?
(Let's not debate in this thread whether this is a good idea. It's consistent
with NSObject, at least.)
Since conformances are globally unique today, I think 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.
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.
The solution I thought of was to downgrade the error to a warning, saying "this
conformance is invalid and will be ignored". This isn't ideal, but it will
probably do the right thing—how often is there a protocol you can add to a type
in multiple, significantly different ways?
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 any
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 those errors to warnings.
"Sorry, this code you have written is going to be ignored, but we'll keep
building anyway?" Seems very fishy.
Options (as I see them):
- Downgrade redeclaration errors to warnings for both conformances and members
- Downgrade conformance redeclaration errors to warnings, but leave member
redeclaration as an error
- 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.
Thoughts, answers? Thanks,
Jordan
P.S. All of this will come back in spades with library evolution
<http://jrose-apple.github.io/swift-library-evolution>, and in particular there
are open issues
<http://jrose-apple.github.io/swift-library-evolution/#open-issues> in the
document around this.
P.P.S. Thanks to Dave Abrahams and Huon Wilson for initial discussion on this.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
