<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 <i class="">worse</i> there, though.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 10, 2016, at 00:14, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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.<br class=""><br class=""><blockquote type="cite" class="">On 10 May 2016, at 08:29, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On May 9, 2016, at 11:23 PM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:<br class=""><br class="">Why wouldn't it completely eliminate NSRange?<br class=""></blockquote><br class="">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]>.<br class=""><br class=""><blockquote type="cite" class="">Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range<Int>?<br class=""></blockquote><br class="">If you had annotations on the APIs to say that they use NSNotFound as a sentinel, yes.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On 10 May 2016, at 05:49, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On May 8, 2016, at 2:10 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hello Swift-Evolution,<br class=""><br class="">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.<br class=""><br class="">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?<br class=""></blockquote><br class=""><br class="">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.<br class=""><br class=""> - Doug<br class=""><br class=""></blockquote><br class=""></blockquote><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>