We thought about that too. The problem is that it’s not always obvious what NSString or NSAttributedString the indexes refer to. For example, most of the NSRegularExpression APIs produce matches in the form of NSTextCheckingResult, which then doesn’t have a reference to the original string.
Jordan > On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution > <swift-evolution@swift.org> wrote: > > Would it be feasible to annotate those and have them appropriately converted > to Range<String.UTF16Index> upon crossing the bridge? Thinking in particular > of TextKit and friends — it'd away with quite a lot of the pain of, e.g., not > having a native struct-y AttributedString. > > Cheers! > Zachary Waldowski > z...@waldowski.me <mailto:z...@waldowski.me> > > > On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution wrote: >> 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@swift.org <mailto:swift-evolution@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 <dgre...@apple.com >>>> <mailto:dgre...@apple.com>> wrote: >>>> >>>> >>>>> On May 9, 2016, at 11:23 PM, David Hart <da...@hartbit.com >>>>> <mailto: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 >>>>>> <mailto:dgre...@apple.com>> wrote: >>>>>> >>>>>> >>>>>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
