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

Douglas Gregor dgregor at apple.com
Tue Jun 28 11:29:39 CDT 2016

> 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

More information about the swift-evolution mailing list