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 <swift- >>>>>> [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
