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 > <[email protected]> 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 <[email protected]> wrote: >> >> >>> On May 9, 2016, at 11:23 PM, David Hart <[email protected]> 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 <[email protected]> wrote: >>>> >>>> >>>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >>>>> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
