[swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

Karl Wagner razielim at gmail.com
Fri Feb 3 10:01:51 CST 2017

> On 2 Feb 2017, at 02:29, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> For people who would suggest that Swift actually take unsigned integers seriously instead of using ‘Int’ everywhere, I sympathize, but I think that ship has sailed—not with us, but with all the existing UIKit code that uses NSInteger for counters. Consistently importing NSUInteger as UInt would be a massive source-break in Swift 4 that just wouldn’t be worth it. Given that, is it better to more closely model what’s in user headers, or to have consistency between user and system headers?

I’ve always considered our handling of signed/unsigned numbers a huge deficiency of Swift.

I appreciate that NSNotFound makes things difficult, but at the same time, eliminating these sentinel values is one of the big benefits for Obj-C developers of moving to Swift. It’s a bit disheartening that Apple’s own frameworks can’t use that. I wonder if the better answer wouldn’t be to introduce an analogue of Optional<NSUInteger> to Objective-C and supplement the signed-with-sentinel methods with optional-unsigned ones, which we would prefer when importing. 3rd-party code could migrate to that new type so that they can be imported in to Swift without sentinels.

That could cause source-breakage for Swift code, but I remember that members of the core-team have said several times that they would like some kind of safe mixed-type arithmetic and comparison to become part of the language one day. I feel that that is ultimately the better way to go in the long-run. I’ve always found it strange that Swift often promotes safety over convenience (e.g. exhaustive switches, trapping on overflow), but then in this one case takes the exact opposite approach.

Since I’m on the subject, I’d also support Array<T>’s index becoming a UInt and all of its index-related methods becoming generic to take any kind of integer. Or, to put it another way, if we could make Array.Index == Any<IntegerProtocol> (an existential), so you could feed indexes in and pull them out in whichever integer type you need — after all, the exact type of the index is not necessarily fundamental to what an Array represents; all that matters is that it’s elements have a contiguous space of integrally-advancing offsets.

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

More information about the swift-evolution mailing list