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

[Jordan Rose]

> On Feb 2, 2017, at 07:33, Jonathan Hull <jhull at gbis.com> wrote:
> 
> 
>> On Feb 2, 2017, at 6:11 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On 2 Feb 2017, at 14:52, Derrick Ho via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Shouldn't NSUInteger always become UInt in swift?
>> 
>> Jordan answers this question in his email:
>> 
>> 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?
> 
> What if we import it as UInt, but have an annotation that the frameworks can add saying that it should be imported as Int instead?  Then have a bot apply that annotation to the system frameworks where it would import it as Int in the current system.  Then there are no source breaking changes (beyond frameworks where you explicitly choose to remove the annotation because the breaking change is considered better than the status quo).

I don’t think we can sell such an annotation. We’d have to first generate a vast number of diffs (or API notes files) for all the APIs currently affected by this, then ask Apple framework owners to review and maintain them going forward. I think that’s a non-starter for us.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170202/1a564bbd/attachment.html>