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