Conceptually, yes, but is that not exactly how it is implemented? https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24 Sincerely, Zachary Waldowski [email protected] On Wed, May 11, 2016, at 01:13 PM, Jordan Rose wrote: > That’s correct, but how would you *make* the String.UTF16Index values > without the reference String? They’re not (guaranteed to be) integers. > > Jordan > > >> On May 10, 2016, at 16:04, Zach Waldowski <[email protected]> wrote: >> >> 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 <[email protected]> >>>> 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- >>>>> [email protected]> 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 >>>>> [email protected] >>>>> >>>>> >>>>> 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- >>>>>>> [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 >>>>> >>>>> _______________________________________________ >>>>> 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
