[swift-evolution] Partial list of open Swift 3 design topics

[Karl]

> On 28 Jun 2016, at 18:29, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>> - <rdar://15821981> Bridge NSRange to “Range<Int>?”
>>> 
>>> I don’t think I can handle writing a proposal for this one, but I’d die for it.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad.
> 
> 
> I’ll try to elaborate on the issues:
> 
> 1) NSRange could be mapped to Range<Int>. This would involve executing bridging code (much like we do for String <-> NSString or Bool <-> BOOL), because NSRange’s location + length representation is different from Range’s lowerBound/upperBound.
> 2) Some NSRanges use location == NSNotFound to indicate “no value”. We would want to bridge these NSRanges to a Range<Int>?, where we location == NSNotFound maps to nil. We cannot guess whether the range treats NSNotFound as special from the API: we’ll need some kind of annotation (e.g., via some kind of Objective-C attribute) that indicates that we should be mapping to an optional value as well as how to identify the nil value. That attribute would then have to be applied to popular APIs.
> 3) When the NSRange is describing indices into a String, we’d need some kind of Objective-C attribute to say that these are indices and (possibly?) point to which NSString* they reference (although the latter is not strictly necessary in the new collection indexing model), so that NSRange can be mapped to Range<String.Index> or Range<String.Index>? (so it needs to compose with #2). That attribute would then have to be applied to popular APIs.
> 4) Similar to #3, we should do the same thing for NSIntegers that represent locations in a String, so those NSIntegers can get mapped to String.Index. There are likely conventions that would map to String.Index? as well, so this also calls for a generalization of #2. That attribute would then have to be applied to popular APIs..
> 
> Although this is on my personal list of things that would be great to clean up for Cocoa, it doesn’t seem feasible for Swift 3 to get it designed, implemented, and rolled out to enough APIs .
> 
> 	- Doug
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

Would it not be possible to replace NSRange with Range<String.Index> on the API surface area we control right now (I.e Foundation)? Foundation could also an extension on String which converts Range<String.Index> <-> NSRange so you can do explicit “bridging", since NSRange is a Foundation type. That’s what it currently does for NSRange<Int>?.

It would make life much easier for people only in Swift, and at the boundary with Obj-C — okay, it’s not really bridging as such, but is it really any more or less convenient to call a method than to perform an “as” cast? You might argue that it’s even more convenient to call a method, since you get code-completion telling you which Obj-C types you can bridge to (and possibly explaining why it’s unexpectedly an optional).

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/a07b644f/attachment.html>