<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2 Feb 2017, at 02:29, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">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 <i class="">massive</i> 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?</div></div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">I’ve always considered our handling of signed/unsigned numbers a huge deficiency of Swift.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">- Karl</div></body></html>