- *Source stability features: *These should be relatively small, but
important. For example, we need a “-std=swift3” sort of compiler flag. We
may also add a way to conditionally enable larger efforts that are under
development but not yet stable - in order to make it easier to experiment
with them.
I am curious whether the team has thoughts on how to organize the compiler
codebase in such a way that new features can be added, and possibly
source-breaking changes made, while still keeping the old functionality
around.
Are any obvious areas that will need refactoring to make this feasible?
(Perhaps they could be turned into StarterBugs.)
How many versions back would the compiler be expected to support? Should
the Swift 5 compiler still support Swift 3 code?
Chris writes:
- Source stability features: These should be relatively small, but important. For example, we need a “-std=swift3” sort of compiler flag. We may also add a way to conditionally enable larger efforts that are under development but not yet stable - in order to make it easier to experiment with them.
I am curious whether the team has thoughts on how to organize the compiler codebase in such a way that new features can be added, and possibly source-breaking changes made, while still keeping the old functionality around.
Are any obvious areas that will need refactoring to make this feasible? (Perhaps they could be turned into StarterBugs.)
I think this would be a great thing to do. We need a few things:
- The actual compiler flag. It is worth bikeshedding how it is spelled. “-std=“ is good inspiration, but clearly the wrong specific name.
- The implementation should be straight forward: the flag should get plumbed through to a field in swift::LangOptions. Code that diverges can then check it.
- Handling divergence in the standard library is another big issue. We have some ideas here, but it depends on having the compiler work done anyway to hook into.
How many versions back would the compiler be expected to support? Should the Swift 5 compiler still support Swift 3 code?
To be determined. Swift 4 should definitely support Swift 3, but Swift 5 perhaps not. We can decide that when Swift 4 is winding down.
-Chris
···
On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
Yes, I've lately been sketching an extension to build-configuration (if ..) statements, to support feature-at-a-time evolution. There are a bunch of edge issues to work through around compiler release channels, name scoping, diagnostics, parser control and so forth. I'll post a draft proposal in a bit.
-Graydon
···
On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
I am curious whether the team has thoughts on how to organize the compiler codebase in such a way that new features can be added, and possibly source-breaking changes made, while still keeping the old functionality around.
- -swift=4
- -swift-version=4
- -language-version=4
- a top-of-file "shebang"-style comment indicating the version,
something like //swift(4), mirroring the "if swift" syntax
···
On Fri, Jul 29, 2016 at 5:27 PM, Chris Lattner <clattner@apple.com> wrote:
On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
Chris writes:
- *Source stability features: *These should be relatively small, but
important. For example, we need a “-std=swift3” sort of compiler flag. We
may also add a way to conditionally enable larger efforts that are under
development but not yet stable - in order to make it easier to experiment
with them.
I am curious whether the team has thoughts on how to organize the compiler
codebase in such a way that new features can be added, and possibly
source-breaking changes made, while still keeping the old functionality
around.
Are any obvious areas that will need refactoring to make this feasible?
(Perhaps they could be turned into StarterBugs.)
I think this would be a great thing to do. We need a few things:
- The actual compiler flag. It is worth bikeshedding how it is spelled.
“-std=“ is good inspiration, but clearly the wrong specific name.
- The implementation should be straight forward: the flag should get
plumbed through to a field in swift::LangOptions. Code that diverges can
then check it.
- Handling divergence in the standard library is another big issue. We
have some ideas here, but it depends on having the compiler work done
anyway to hook into.
How many versions back would the compiler be expected to support? Should
the Swift 5 compiler still support Swift 3 code?
To be determined. Swift 4 should definitely support Swift 3, but Swift 5
perhaps not. We can decide that when Swift 4 is winding down.
Here are a few thoughts:
-swift=4
-swift-version=4
-swift-version seems like the best option to me, but Jordan will have a strong opinion. I think he’s crazy busy with Swift 3 work until late next week.
-Chris
···
On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
-language-version=4
a top-of-file "shebang"-style comment indicating the version, something like //swift(4), mirroring the "if swift" syntax
On Fri, Jul 29, 2016 at 5:27 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Chris writes:
- Source stability features: These should be relatively small, but important. For example, we need a “-std=swift3” sort of compiler flag. We may also add a way to conditionally enable larger efforts that are under development but not yet stable - in order to make it easier to experiment with them.
I am curious whether the team has thoughts on how to organize the compiler codebase in such a way that new features can be added, and possibly source-breaking changes made, while still keeping the old functionality around.
Are any obvious areas that will need refactoring to make this feasible? (Perhaps they could be turned into StarterBugs.)
I think this would be a great thing to do. We need a few things:
- The actual compiler flag. It is worth bikeshedding how it is spelled. “-std=“ is good inspiration, but clearly the wrong specific name.
- The implementation should be straight forward: the flag should get plumbed through to a field in swift::LangOptions. Code that diverges can then check it.
- Handling divergence in the standard library is another big issue. We have some ideas here, but it depends on having the compiler work done anyway to hook into.
How many versions back would the compiler be expected to support? Should the Swift 5 compiler still support Swift 3 code?
To be determined. Swift 4 should definitely support Swift 3, but Swift 5 perhaps not. We can decide that when Swift 4 is winding down.
* Do we want to be able to mix files using different versions of Swift in the same module?
* Do we want to extend these backwards compatibility features beyond the standard library to other modules?
If the answer to both is "yes", then the compiler can just treat the version of the `Swift` module specially, using it to adjust the language syntax in addition to the standard library interface. The command-line switch can be one that provides a default version for imports with unspecified versions, like:
--version Swift=3.1 --version SomeJSON=1.2
···
On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
• a top-of-file "shebang"-style comment indicating the version, something like //swift(4), mirroring the "if swift" syntax
:-) I missed this thread. -swift-version is all right. It doesn’t immediately sound nice (a bit wordy) but I don’t have anything better.
If I’m really getting nitpicky, I might note that we don’t really use = options in swiftc as much as separated operations (-swift-version 4).
Jordan
···
On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev <swift-dev@swift.org> wrote:
On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Here are a few thoughts:
-swift=4
-swift-version=4
-swift-version seems like the best option to me, but Jordan will have a strong opinion. I think he’s crazy busy with Swift 3 work until late next week.
Importing the right version of a module (such as the standard library) when
more than one are available is just a search-paths problem. Supporting
multiple versions of the language's syntax and ABI, though, as far as I can
tell, requires the switch to be deeply baked into the compiler.
So I don't really see how we can get away with a "general" solution, beyond
perhaps some SwiftPM support for libraries that provide source or binaries
for multiple language versions.
···
On Wed, Aug 3, 2016 at 12:44 PM, Douglas Gregor <dgregor@apple.com> wrote:
> On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev < > swift-dev@swift.org> wrote:
>
>> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> • a top-of-file "shebang"-style comment indicating the version,
something like //swift(4), mirroring the "if swift" syntax
>
> `import Swift 3.1`?
>
> I think this brings up two interesting questions:
>
> * Do we want to be able to mix files using different versions of Swift
in the same module?
No. It simplifies the problem greatly if the whole module is compiled with
a single Swift version.
> * Do we want to extend these backwards compatibility features beyond the
standard library to other modules?
If we can design generally-useful features for handling language
versioning, that the standard library can adopt, that would be great.
On Tue, Sep 6, 2016 at 10:37 AM, Jordan Rose <jordan_rose@apple.com> wrote:
On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev < > swift-dev@swift.org> wrote:
On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
Here are a few thoughts:
- -swift=4
- -swift-version=4
-swift-version seems like the best option to me, but Jordan will have a
strong opinion. I think he’s crazy busy with Swift 3 work until late next
week.
:-) I missed this thread. -swift-version is all right. It doesn’t
immediately sound nice (a bit wordy) but I don’t have anything better.
If I’m really getting nitpicky, I might note that we don’t really use =
options in swiftc as much as separated operations (-swift-version 4).