Right, I 100% get it. :) This is a difficult problem space, and I'm sure you folks are aware that that difficulty is also reflected in how brutal it is to use all of these derivative string-range-based things in Swift right now. In this case, having no answer to this problem is worse than not having the API at all — check Stack Overflow or GitHub for how often a "just paste this in" String.Index.init(_: Int) comes up. As far as NSTextCheckingResult goes, its ranges are always in the "indices" always in the space of the original string… do I have that right? So it would be programmer error to use those ranges in the wrong string just like it is with any Range<String.UTF16Index> today. Zach Waldowski On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote: > By the way, this doesn’t mean it can’t be done, or that we can’t > decide on some kind of partial solution! It just means that it needs > to be carefully considered and explicitly addressed. > > Jordan > > >> On May 10, 2016, at 15:49, Jordan Rose <jordan_r...@apple.com> wrote: >> >> 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- >>> evolut...@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 >>> >>> >>> 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- >>>>> evolut...@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> >>>>>> 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- >>>>>>>>> evolut...@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 >>>> >>>> _________________________________________________ >>>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution