<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 Jan 17, 2016, at 13:01, Chris Lattner via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 10:19 AM, Jens Alfke via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 5:19 AM, Marco Masser via swift-users &lt;<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Swift imports&nbsp;</span><span class="" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;">NSUInteger</span><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">&nbsp;in Objective-C APIs as&nbsp;</span><span class="" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;">Int</span><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">, but only for Frameworks like Foundation and AppKit. For other code,&nbsp;</span><span class="" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;">NSUInteger</span><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">&nbsp;is imported simply as&nbsp;</span><span class="" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;">UInt</span><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">.</span></div></blockquote></div><br class=""><div class="">Really? I’d never noticed that. It seems wrong to me, since NSUInteger is clearly an unsigned type, so it should map to Uint.</div></div></div></blockquote><br class=""></div><div class="">Yes, it is intentional, we do the same for size_t.</div><div class=""><br class=""></div><div class="">As far as I know, there is no way to get the same behavior for your own code. &nbsp;It would be reasonable to introduce a clang attribute for that though.</div></div></div></blockquote><br class=""></div><div>I've been meaning to do an investigation to see about just doing this automatically for user code—i.e. how many of the top frameworks in CocoaPods are using NSUInteger to really mean "word-sized unsigned integer", as opposed to "the Apple framework uses NSUInteger here so I will too".</div><div><br class=""></div><div>By the way, the original rational for the NSUInteger -&gt; Int mapping is mostly that our frameworks weren't consistent about the use of NSInteger/CFIndex vs. NSUInteger. Since Swift makes signedness conversions explicit, this would become an unnecessary burden. (For example,&nbsp;<a href="https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UITableViewDataSource_Protocol/index.html#//apple_ref/occ/intfm/UITableViewDataSource/numberOfSectionsInTableView:" class="">-[UITableViewDataSource numberOfSectionsInTableView:]</a>&nbsp; uses NSInteger, but&nbsp;<a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/index.html#//apple_ref/occ/instp/NSArray/count" class="">NSArray.count</a>&nbsp;uses NSUInteger.) We found that there would almost never be an NSUInteger value that actually went beyond NSIntegerMax, at least partly because this is the representation of&nbsp;<a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Constants/#//apple_ref/doc/constant_group/NSNotFound" class="">NSNotFound</a>. In cases where there <i class="">was</i>&nbsp;a value that went past NSIntegerMax, it was usually a unique identifier or a bitfield, i.e. not something that needed arithmetic operations. Since Swift doesn't have strange undefined behavior around its bitwise operations for signed types, there's no problem bringing these sorts of values in as Int as well. Similar arguments apply to size_t and rsize_t, which never actually have to represent an integer spanning half of the address space. (If you actually need such a thing for non-size-related reasons, the right type would be uintptr_t, which is imported as UInt.)</div><div><br class=""></div><div>One exception is that we do keep the base of NS_OPTIONS enums as NSUInteger if so specified. In that case, we want to keep the integer constant valid as is and not force a spurious minus sign on the 32nd option.</div><div><br class=""></div><div>The main loss here is that NSUInteger always carries the precondition of the value being non-negative, but again, existing frameworks already weren't consistent about that, so we considered it an acceptable trade-off.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>