[PrintAsObjC] More tweaks to +new unavailability #13422
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Another follow-up to 49c65fa. We've seen a few people run into this and not know what changed. rdar://problem/35942058
The general policy has been that even if something crashes at run time, we don't make it a hard error in Swift 4 mode (or Swift 3 mode!) if it wasn't a hard error in Swift 4.0 (3.0). In this case, we thought we could get away with it, and then it turns out it actually caused some problems. (And as 2bc0106 shows, we can still make mistakes.) This change isn't perfect because the diagnostic appears in /clients/ rather than in the module that's being compiled as Swift 4 (instead of Swift 5). But it still means that someone who hasn't changed /anything/ from a valid Swift 4.0 project will be able to compile without any changes, even if they were relying on being able to call +new when -init was unavailable for some reason. More rdar://problem/35942058
|
@JaviSoto, @DougGregor, what do you think of this one? I think we got the most important change already, but this might still improve the state of the world. |
|
@swift-ci Please test macOS |
|
@swift-ci Please smoke test Linux |
|
I love the idea of the explicit error message. The policy for avoiding breaking changes is totally fair too. |
|
Don't stress about it, Javi. It was listed as a starter bug and none of us thought too deeply about it either. That's the reviewer's responsibility more than a spare-time contributor's! We're still in a better place for you adding this. :-) |
jrose-apple
added a commit
to jrose-apple/swift
that referenced
this pull request
Dec 14, 2017
[PrintAsObjC] More tweaks to +new unavailability rdar://problem/35942058
|
Thank you Jordan <3 |
jrose-apple
added a commit
that referenced
this pull request
Dec 14, 2017
…#13433) [PrintAsObjC] More tweaks to +new unavailability rdar://problem/35942058
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another follow-up to #12295. Downgrades
+newunavailability to deprecation in pre-Swift-5 modes. The general policy has been that even if something crashes at run time, we don't make it a hard error in Swift 4 mode (or Swift 3 mode!) if it wasn't a hard error in Swift 4.0 (3.0). In this case, we thought we could get away with it, and then it turns out it actually caused some problems. (And as #13320 shows, we can still make mistakes.)This change isn't perfect because the diagnostic appears in clients rather than in the module that's being compiled as Swift 4 (instead of Swift 5). But it still means that someone who hasn't changed anything from a valid Swift 4.0 project will be able to compile without any changes, even if they were relying on being able to call
+newwhen-initwas unavailable for some reason.Finally, include a message when making
+newunavailable / deprecated. We've seen a few people run into this and not know what changed.rdar://problem/35942058