I’m not sure we’re going to stick to that in the future. It’s possible we’ll want String to support UTF-8 buffers as well.
Jordan > On May 11, 2016, at 10:15, Zach Waldowski <[email protected]> wrote: > > Conceptually, yes, but is that not exactly how it is implemented? > https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24 > > <https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24> > > Sincerely, > Zachary Waldowski > [email protected] <mailto:[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] >>> <mailto:[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] >>>>> <mailto:[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 >>>>>> <[email protected] <mailto:[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] <mailto:[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 >>>>>>>> <[email protected] <mailto:[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] >>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On May 9, 2016, at 11:23 PM, David Hart <[email protected] >>>>>>>>>> <mailto:[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] >>>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >>>>>>>>>>>> <[email protected] <mailto:[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] <mailto:[email protected]> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
