[swift-evolution] NSRange and Range

[Jordan Rose]

One particular concern we've had is that many NSRanges aren’t Range<Int>; they’re Range<String.UTF16Index>. I suppose things wouldn’t get any worse there, though.

Jordan


> On May 10, 2016, at 00:14, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> But it’s reasonably implementable? I guess the answer is yes if you have already faced the same bridging concerns with NSArray/Array. I’de really like this going forward, but I don’t know how confident I am in writing a proposal.
> 
>> On 10 May 2016, at 08:29, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> 
>>> On May 9, 2016, at 11:23 PM, David Hart <david at hartbit.com> wrote:
>>> 
>>> Why wouldn't it completely eliminate NSRange?
>> 
>> Because NSRange has a different representation than Range<Int> (start+length vs. start/end), a pointer-to-NSRange has to come in as Unsafe(Mutable)Pointer<NSRange> rather than Unsafe(Mutable)Pointer<Range<Int>>. It’s the same reason that (e.g.), an NSArray** parameter comes in as UnsafeMutablePointer<NSArray> rather than UnsafeMutablePointer<[AnyObject]>.
>> 
>>> Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range<Int>?
>> 
>> If you had annotations on the APIs to say that they use NSNotFound as a sentinel, yes.
>> 
>> 	- Doug
>> 
>>> 
>>>> On 10 May 2016, at 05:49, Douglas Gregor <dgregor at apple.com> wrote:
>>>> 
>>>> 
>>>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> Hello Swift-Evolution,
>>>>> 
>>>>> I spent some time coding on Linux with Swift 3 (latest developement snapshot) and corelibs-foundation and I’ve hit one major hurdle: passing and converting NSRange and Range around between the different stdlib and Foundation APIs - specifically in regards to String.
>>>>> 
>>>>> Is there a plan to simplify those pain points by converting all corelibs-foundation APIs to accept/return Range on String instead of NSRange? In that case, can’t we get rid of NSRange completely?
>>>> 
>>>> 
>>>> One idea that had come up before was to bridge NSRange to Range<Int>, although it wouldn’t completely eliminate NSRange because the two types are not representationally identical.
>>>> 
>>>> - Doug
>>>> 
>>> 
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/7a174901/attachment.html>