> On 28 Jun 2016, at 18:29, Douglas Gregor via swift-evolution
> <[email protected]> wrote:
>
>>
>> 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] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
Would it not be possible to replace NSRange with Range<String.Index> on the API
surface area we control right now (I.e Foundation)? Foundation could also an
extension on String which converts Range<String.Index> <-> NSRange so you can
do explicit “bridging", since NSRange is a Foundation type. That’s what it
currently does for NSRange<Int>?.
It would make life much easier for people only in Swift, and at the boundary
with Obj-C — okay, it’s not really bridging as such, but is it really any more
or less convenient to call a method than to perform an “as” cast? You might
argue that it’s even more convenient to call a method, since you get
code-completion telling you which Obj-C types you can bridge to (and possibly
explaining why it’s unexpectedly an optional).
Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
