> On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>> - <rdar://15821981> Bridge NSRange to “Range<Int>?”
>>
>> I don’t think I can handle writing a proposal for this one, but I’d die for
>> it.
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Will this work the way people expect, especially given how NSString handles
> unicode vs Swift String and the various views? My suspicion is at least a
> chunk of the things people imagine doing with the bridged NSRange won’t
> actually work and they’ll be sad.
I’ll try to elaborate on the issues:
1) NSRange could be mapped to Range<Int>. This would involve executing bridging
code (much like we do for String <-> NSString or Bool <-> BOOL), because
NSRange’s location + length representation is different from Range’s
lowerBound/upperBound.
2) Some NSRanges use location == NSNotFound to indicate “no value”. We would
want to bridge these NSRanges to a Range<Int>?, where we location == NSNotFound
maps to nil. We cannot guess whether the range treats NSNotFound as special
from the API: we’ll need some kind of annotation (e.g., via some kind of
Objective-C attribute) that indicates that we should be mapping to an optional
value as well as how to identify the nil value. That attribute would then have
to be applied to popular APIs.
3) When the NSRange is describing indices into a String, we’d need some kind of
Objective-C attribute to say that these are indices and (possibly?) point to
which NSString* they reference (although the latter is not strictly necessary
in the new collection indexing model), so that NSRange can be mapped to
Range<String.Index> or Range<String.Index>? (so it needs to compose with #2).
That attribute would then have to be applied to popular APIs.
4) Similar to #3, we should do the same thing for NSIntegers that represent
locations in a String, so those NSIntegers can get mapped to String.Index.
There are likely conventions that would map to String.Index? as well, so this
also calls for a generalization of #2. That attribute would then have to be
applied to popular APIs..
Although this is on my personal list of things that would be great to clean up
for Cocoa, it doesn’t seem feasible for Swift 3 to get it designed,
implemented, and rolled out to enough APIs .
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
