Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-8849] swiftc should have flag to print supported swift versions in a machine-readable fashion #51355

Open
lilyball mannequin opened this issue Sep 25, 2018 · 6 comments
Open

Comments

@lilyball
Copy link
Mannequin

@lilyball lilyball mannequin commented Sep 25, 2018

Previous ID SR-8849
Radar None
Original Reporter @lilyball
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, Driver
Assignee None
Priority Medium

md5: 18877001790bcc5b9c206215ac14c3af

Issue Description:

The swiftc tool should have a compiler flag that prints the supported Swift versions (suitable for passing to -swift-version) in a stable machine-readable format. AFAICT right now the only way to list all supported versions is to pass an invalid major version and read the error message (which isn't a stable machine-readable format, it's a human-readable string).

The use-case here is automated tooling that needs to select among a set of supported Swift versions to specify (e.g. CocoaPods generating an xcodeproj).

@lilyball
Copy link
Mannequin Author

@lilyball lilyball mannequin commented Sep 25, 2018

It's also probably worth distinguishing between "fully supported and shipped" versions and "versions which are accepted but aren't fully baked yet". By that I mean the Xcode 10 (Swift 4.2) compiler actually accepts -swift-version 5, but version 5 is still in development and tooling needs to know that even though version 5 is accepted by the compiler, it shouldn't be chosen by the tooling.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Sep 26, 2018

I'm still a little confused on the use case here. Any particular sources have an intrinsic Swift version; that can't just change because the compiler is different.

@lilyball
Copy link
Mannequin Author

@lilyball lilyball mannequin commented Sep 26, 2018

Sure they can. What do you think #if swift(>=4.2) is for?

@lilyball
Copy link
Mannequin Author

@lilyball lilyball mannequin commented Sep 26, 2018

There's also plenty of Swift source out there that is simple enough that it is compatible with multiple major Swift versions without any source-level changes. I'm pretty sure at least one of my Swift libraries required zero source changes to go from Swift 3 to Swift 4.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Sep 26, 2018

I guess that's true, but I still don't see how it translates to a feature here. If my file supports Swift 4.2 and Swift 5, I always want to use Swift 5 mode when it's available. If it just supports Swift 4.2, I don't have a choice. That makes me think that the actual compiler version is what's important, not the list of supported versions.

…except for 4.2, which throws off the whole "just use the major version thing", and now that it's happened once I can't really say it'll never happen again. Hm.

It's also unclear what'll happen with Swift versions in the future, after Swift 5.

@lilyball
Copy link
Mannequin Author

@lilyball lilyball mannequin commented Oct 1, 2018

I'm also not comfortable relying on the idea that the Swift compiler version tracks the Swift Language version.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant