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 <dgre...@apple.com> wrote: > > >> On May 9, 2016, at 11:23 PM, David Hart <da...@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 <dgre...@apple.com> wrote: >>> >>> >>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >>>> <swift-evolution@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution