Why wouldn't it completely eliminate NSRange? Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range<Int>?
> 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
