[swift-evolution] NSRange and Range

[Zach Waldowski]

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 <jordan_rose at apple.com> 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-
>>> evolution at swift.org> 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
>>> zach at waldowski.me
>>>
>>>
>>> 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-
>>>>> evolution at swift.org> 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 <dgregor at apple.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On May 9, 2016, at 11:23 PM, David Hart <david at hartbit.com>
>>>>>>> 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 <dgregor at apple.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution <swift-
>>>>>>>>> evolution at swift.org> 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
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _________________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/17f44b6e/attachment.html>