Re: [swift-evolution] NSRange and Range

That makes sense. However, wouldn't this still be workable in terms of bridging? If UTF16Index had an alternate representation for Swift- side UTF-8 storage, that wouldn't ever come up for roundtripping across the bridge. The offsets that come back from Foundation would always be "UTF-16 indices

Re: [swift-evolution] NSRange and Range

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 wrote: > > Conceptually, yes, but is that not exactly how it is implemented? >

Re: [swift-evolution] NSRange and Range

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 wrote: > > Right, I 100% get it. :) This is a difficult problem space, and I'm sure

Re: [swift-evolution] NSRange and Range

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

Re: [swift-evolution] NSRange and Range

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 wrote: > > We thought about that

Re: [swift-evolution] NSRange and Range

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.

Re: [swift-evolution] NSRange and Range

Would it be feasible to annotate those and have them appropriately converted to Range 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

Re: [swift-evolution] NSRange and Range

One particular concern we've had is that many NSRanges aren’t Range; they’re Range. I suppose things wouldn’t get any worse there, though. Jordan > On May 10, 2016, at 00:14, David Hart via swift-evolution > wrote: > > But it’s reasonably implementable? I guess

Re: [swift-evolution] NSRange and Range

Sent from my iPhone > On May 10, 2016, at 12:14 AM, David Hart 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

Re: [swift-evolution] NSRange and Range

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

Re: [swift-evolution] NSRange and Range

> On May 9, 2016, at 11:23 PM, David Hart wrote: > > Why wouldn't it completely eliminate NSRange? Because NSRange has a different representation than Range (start+length vs. start/end), a pointer-to-NSRange has to come in as Unsafe(Mutable)Pointer rather than

Re: [swift-evolution] NSRange and Range

Why wouldn't it completely eliminate NSRange? Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range? > On 10 May 2016, at 05:49, Douglas Gregor wrote: > > >> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution >>

Re: [swift-evolution] NSRange and Range

> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution > 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 >

[swift-evolution] NSRange and Range

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