Yeah, that's what I want - more "annotations" cluttering up my Objective C headers to make Swift happy.
No thanks. There's enough noise introduced already. > On Feb 2, 2017, at 07:33, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > >> On Feb 2, 2017, at 6:11 AM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On 2 Feb 2017, at 14:52, Derrick Ho via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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). > > Thanks, > Jon > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
