4 ms·
The real issue I encounter isn't Swift itself, it's the constant Swift-specific SDK changes... When the `NSNotification.Name` Swift APIs change every year, it
by favorited 8y ago
The real issue I encounter isn't Swift itself, it's the constant Swift-specific SDK changes... When the `NSNotification.Name` Swift APIs change every year, it means migration is still painful.
It's not the Great Renaming, and it might not be fair to the Swift project itself, but unless I can compile a project using the 10.13 and 10.14 SDKs without source changes (which you can in Objective-C), the impression is that Swift doesn't have source compatibility.
- saagarjha 8y agoAs I'm sure you're aware, these are changes in AppKit, not Swift. AFAIK the Swift project has no control over how this API is exposed.
- favorited 8y agoI'm not disputing that. What I am saying is that, until the Swift representations of the Apple platform SDKs are stable between releases (like it is in Objective-C), then the majority of Swift codebases will not be source compatible the way Objective-C codebases are.
- dbaupp 8y agoThe Swift compiler does a lot of automatic "rewrites" of (Objective) C headers to be more Swifty, so it does have some measure of control. That said, the largest changes are guided by annotations associated with the headers.
- Nullabillity 8y agoThey're both ran by Apple, so that's a distinction without a difference.
- saagarjha 8y agoUnfortunately, this isn't how Apple works. Both teams are more or less separate in this case. Sure, the Swift team can certainly send information over to the AppKit team, but they don't have the ability to make any decisions on naming conventions.