[swift-evolution] NSRange and Range

[Zach Waldowski]

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
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160510/1068c54a/attachment.html>