The review of SE-0151 “Package Manager Swift Language Compatibility Version" begins now and runs through February 13, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
The review of SE-0151 “Package Manager Swift Language Compatibility Version" begins now and runs through February 13, 2017. The proposal is available here:
I’ve one question regarding this proposal:
Why use the list `swiftLanguageVersions` instead of a simple `swiftLanguageVersion: Int = 3`?
What’s the advantage of being able to specify `[3,4]`?
If you already have a version 4 compiler, that one will be used anyway and if the source really is compatible with both versions,
it does not make any difference whether it will be run in version 3 or version 4 mode.
So just setting it to `3` has the same effect, right?
I think it’s enough to specify something like „this source is intended to be compiled in swift version 3 mode“.
Most of the time, that’s all you can specify anyway, because you don’t know which future versions happen to be compatible.
I guess allowing a list of versions to be specified is interesting for continuous integration.
That would allow people to test their code under all intended supported version.
Dimitri
···
On 8 Feb 2017, at 08:19, Martin Waitz via swift-evolution <swift-evolution@swift.org> wrote:
Hello,
The review of SE-0151 “Package Manager Swift Language Compatibility Version" begins now and runs through February 13, 2017. The proposal is available here:
I’ve one question regarding this proposal:
Why use the list `swiftLanguageVersions` instead of a simple `swiftLanguageVersion: Int = 3`?
What’s the advantage of being able to specify `[3,4]`?
If you already have a version 4 compiler, that one will be used anyway and if the source really is compatible with both versions,
it does not make any difference whether it will be run in version 3 or version 4 mode.
So just setting it to `3` has the same effect, right?
I think it’s enough to specify something like „this source is intended to be compiled in swift version 3 mode“.
Most of the time, that’s all you can specify anyway, because you don’t know which future versions happen to be compatible.
The review of SE-0151 “Package Manager Swift Language Compatibility Version" begins now and runs through February 13, 2017. The proposal is available here:
The Swift Package Manager will allow package authors to specify a list of compatibility modes.
This proposal provides a mechanism to implement that point.
I believe that the reason this was desired is because we expect that package authors may wish to conditionally adopt new Swift 4 language features without breaking their ability to build with Swift 3, using conditional compilation blocks, e.g.
With this proposal, you can do this by specifying [3, 4], in which case the Swift 4 compiler will compile it as Swift 4 code, and use the code inside the conditional compilation block, while the Swift 3 compiler will also be able to compile it (as Swift 3 code), skipping the conditional compilation block.
If you were only able to specify "3" instead, the Swift 4 compiler would pass `-swift-version 3` when compiling this code, and would skip the conditional compilation block. As such it would not be possible to use any Swift 4 language features unless you set your Swift language compatibility version to "4", at which point it could no longer be built by the Swift 3 compiler.
- Rick
···
On Feb 7, 2017, at 11:19 PM, Martin Waitz via swift-build-dev <swift-build-dev@swift.org> wrote:
I’ve one question regarding this proposal:
Why use the list `swiftLanguageVersions` instead of a simple `swiftLanguageVersion: Int = 3`?
What’s the advantage of being able to specify `[3,4]`?
If you already have a version 4 compiler, that one will be used anyway and if the source really is compatible with both versions,
it does not make any difference whether it will be run in version 3 or version 4 mode.
So just setting it to `3` has the same effect, right?
I think it’s enough to specify something like „this source is intended to be compiled in swift version 3 mode“.
Most of the time, that’s all you can specify anyway, because you don’t know which future versions happen to be compatible.
I guess allowing a list of versions to be specified is interesting for
continuous integration.
That would allow people to test their code under all intended supported version.
That is a valid use-case, but should be specified somewhere else.
In your `.travis.yml` (or whatever), you could specify to compile your package (and all dependencies)
with different versions of the swift tools.
However, all these different tool versions would still use the per-package `swiftLanguageVersion` to select the right compiler mode for each package.
This way, you can test that everything really builds and links with different tool versions.
I see no reason to include a list of versions in the manifest.
That only creates ambiguities ("works for me" if you happen to have the right tool version).
-- Martin
···
Am 2017-02-08 08:54, schrieb Dimitri Racordon via swift-evolution:
I believe that the reason this was desired is because we expect that
package authors may wish to conditionally adopt new Swift 4 language
features without breaking their ability to build with Swift 3, using
conditional compilation blocks, e.g.
With this proposal, you can do this by specifying [3, 4], in which
case the Swift 4 compiler will compile it as Swift 4 code, and use the
code inside the conditional compilation block, while the Swift 3
compiler will also be able to compile it (as Swift 3 code), skipping
the conditional compilation block.