<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div style="font-family:Arial;">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 how NSString understands it", which Swift would necessarily understand because it implements -characterAtIndex: for the bridge wrapper.<br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div id="sig40804545"><div class="signature">Zach</div>
</div>
<div>&nbsp;</div>
<div>On Wed, May 11, 2016, at 01:19 PM, Jordan Rose wrote:<br></div>
<blockquote type="cite"><div>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.<br></div>
<div>&nbsp;</div>
<div>Jordan<br></div>
<div>&nbsp;</div>
<div style="font-family:Arial;">&nbsp;</div>
<div><blockquote type="cite"><div>On May 11, 2016, at 10:15, Zach Waldowski &lt;<a href="mailto:zach@waldowski.me">zach@waldowski.me</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;</div>
<div><div><div style="font-family:Arial;">Conceptually, yes, but is that not exactly how it is implemented?&nbsp;<a href="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</a><br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div>Sincerely,<br></div>
<div>&nbsp; Zachary Waldowski<br></div>
<div>&nbsp;&nbsp;<a href="mailto:zach@waldowski.me">zach@waldowski.me</a><br></div>
</div>
<div>&nbsp;<br></div>
<div>&nbsp;<br></div>
<div>On Wed, May 11, 2016, at 01:13 PM, Jordan Rose wrote:<br></div>
<blockquote type="cite"><div>That’s correct, but how would you <i>make</i>&nbsp;the String.UTF16Index values without the reference String? They’re not (guaranteed to be) integers.<br></div>
<div>&nbsp;<br></div>
<div>Jordan<br></div>
<div>&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><blockquote type="cite"><div>On May 10, 2016, at 16:04, Zach Waldowski &lt;<a href="mailto:zach@waldowski.me">zach@waldowski.me</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div><div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">As far as&nbsp;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&lt;String.UTF16Index&gt; today.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div>Zach Waldowski<br></div>
</div>
<div>&nbsp;<br></div>
<div>&nbsp;<br></div>
<div>On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:<br></div>
<blockquote type="cite"><div>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.<br></div>
<div>&nbsp;<br></div>
<div>Jordan<br></div>
<div>&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><blockquote type="cite"><div>On May 10, 2016, at 15:49, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div style="word-wrap:break-word;-webkit-line-break:after-white-space;"><div>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.<br></div>
<div>&nbsp;<br></div>
<div>Jordan<br></div>
<div>&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><blockquote type="cite"><div>On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div><div style="font-family:Arial;">Would it be feasible to annotate those and have them appropriately converted to Range&lt;String.UTF16Index&gt; 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.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div>Cheers!<br></div>
<div>&nbsp; Zachary Waldowski<br></div>
<div>&nbsp;&nbsp;<a href="mailto:zach@waldowski.me">zach@waldowski.me</a><br></div>
</div>
<div>&nbsp;<br></div>
<div>&nbsp;<br></div>
<div>On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution wrote:<br></div>
<blockquote type="cite"><div>One particular concern we've had is that many NSRanges aren’t Range&lt;Int&gt;; they’re Range&lt;String.UTF16Index&gt;. I suppose things wouldn’t get any <i>worse</i>&nbsp;there, though.<br></div>
<div>&nbsp;<br></div>
<div>Jordan<br></div>
<div>&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><blockquote type="cite"><div>On May 10, 2016, at 00:14, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><div><div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<blockquote type="cite"><div style="font-family:Arial;">On 10 May 2016, at 08:29, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<blockquote type="cite"><div style="font-family:Arial;">On May 9, 2016, at 11:23 PM, David Hart &lt;<a href="mailto:david@hartbit.com">david@hartbit.com</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">Why wouldn't it completely eliminate NSRange?<br></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">Because NSRange has a different representation than Range&lt;Int&gt; (start+length vs. start/end), a pointer-to-NSRange has to come in as Unsafe(Mutable)Pointer&lt;NSRange&gt; rather than Unsafe(Mutable)Pointer&lt;Range&lt;Int&gt;&gt;. It’s the same reason that (e.g.), an NSArray** parameter comes in as UnsafeMutablePointer&lt;NSArray&gt; rather than UnsafeMutablePointer&lt;[AnyObject]&gt;.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<blockquote type="cite">Are you thinking of NSNotFound? Could we migrate those APIs to return an Optional Range&lt;Int&gt;?<br></blockquote><div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">If you had annotations on the APIs to say that they use NSNotFound as a sentinel, yes.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;"><span style="white-space:pre;"></span>- Doug<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<blockquote type="cite"><div style="font-family:Arial;">&nbsp;<br></div>
<blockquote type="cite"><div style="font-family:Arial;">On 10 May 2016, at 05:49, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<blockquote type="cite"><div style="font-family:Arial;">On May 8, 2016, at 2:10 PM, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">Hello Swift-Evolution,<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">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?<br></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">One idea that had come up before was to bridge NSRange to Range&lt;Int&gt;, although it wouldn’t completely eliminate NSRange because the two types are not representationally identical.<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">- Doug<br></div>
<div style="font-family:Arial;">&nbsp;<br></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
<div style="font-family:Arial;">_______________________________________________<br></div>
<div style="font-family:Arial;">swift-evolution mailing list<br></div>
<div style="font-family:Arial;"><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div style="font-family:Arial;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</div>
</div>
</blockquote></div>
<div style="font-family:Arial;">&nbsp;<br></div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
</div>
<div style="font-family:Arial;">_______________________________________________<br></div>
<div style="font-family:Arial;">swift-evolution mailing list<br></div>
<div style="font-family:Arial;"><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div style="font-family:Arial;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</div>
</blockquote></div>
</div>
</div>
</blockquote></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
</div>
</div>
</blockquote></div>
</blockquote><div style="font-family:Arial;">&nbsp;<br></div>
</div>
</div>
</blockquote></div>
</blockquote><div style="font-family:Arial;">&nbsp;</div>
</body>
</html>