-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Foundation] add additional conformances and functionality to NSRange #9654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Foundation] add additional conformances and functionality to NSRange #9654
Conversation
@swift-ci please test |
// FIXME(ABI)#75 (Conditional Conformance): this API should be an extension on Range. | ||
// Can't express it now because the compiler does not support conditional | ||
// extensions with type equality constraints. | ||
public func toRange() -> Range<Int>? { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you're at it, might it be appropriate to address this FIXME?
extension Range where Bound == Int {
public init?(_ x: NSRange) {
if x.location == NSNotFound { return nil }
self.init(uncheckedBounds: (x.location, x.location + x.length))
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a cherry-pick, we can't remove this API without breaking source compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, I didn't notice that this is a cherry pick, and I guess I must have missed the initial commit to master.
Not suggesting that you remove the API, just asking whether now's the time when this can be deprecated (on master) and the originally intended initializer added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to address that FIXME shortly in another PR...
Please also cherry-pick #9507 as part of this PR; it's required so this change doesn't break source compatibility. |
Fix a silly gap in my fix for rdar://problem/31104415, where imported types that gain conformances through their overlays were still getting errors. Fixes SR-4820 / rdar://problem/32134724.
@swift-ci please test |
Build failed |
Build failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are some important improvements that seem reasonable to me. These have also been tested.
Explanation: NSRange is used widely in a number of Cocoa APIs; it has a few free-floating functions used to manipulate and parse ranges. These functiosn should be hoisted into NSRange and protocols should be adopted where appropriate.
NSRange can be converted to a string; therefore it should adopt CustomStringConvertible and CustomDebugStringConvertible. It also has a free floating function NSEqualRanges which can more appropriately be expressed as adopting Equatable. Furthermore NSMaxRange can be exposed as upperBound to fall in line with Range. Also it can move NSUnionRange to be a member function to create new and mutate NSRanges.
Scope: This is an additive API change for NSRange. It has no language changes.
Radar (and possibly SR Issue): rdar://problem/21626767
Risk: It is possible that existing projects may implement Hashable or Equatable for NSRange, however the authoritative source for these definitions should be determined by the framework that determines that type.
Testing: This was tested against the existing set of tests for NSRange.