As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up to be. Ted posted details of the Swift 3 release process last week (https://swift.org/blog/swift-3-0-release-process/\) and I just updated the main swift-evolution README.md file (https://github.com/apple/swift-evolution\) with some updated details about the goals of Swift 3.
This release is shaping up to be a really phenomenal release that will redefine the feel of Swift and make a major leap towards maturing the Swift language and development experience. We have had a focus on getting to source stability, with the forward-looking goal of making Swift 4 as source compatible with Swift 3 as we can reasonably accomplish. It tackled API naming head on (which is one of the hardest problems in computer science [1]), made major improvements to the consistency and feel of the language, and has several nice across the board additions.
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
I expect discussion and planning for Swift 3.x and Swift 4 to start sometime around August of this year. Until then, it is very important that we as a community stay focused on the goals of Swift 3: I’d really prefer us all to resist the urge to discuss major blue sky features for future releases. We would also like to put a significant amount of effort into bug fixing and quality refinements as well, which means that the core team will be proactively deferring evolution proposals to later releases that don’t align with the Swift 3 goals, especially those that are strictly additive.
Thank you for all of the amazing community that has developed on this list, it is great to work with you all! Let us know if you have any questions,
-Chris
[1] It is well known that the two hard problems in Computer Science are naming, cache invalidation, and off-by-one errors.
Oh, good! I was getting worried about that. Are there any particular topics that we should drop or discuss?
- Dave Sweeris
···
On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
With the generics and ABI stability goals getting pushed out to a future release, how does that affect the plans for Swift concurrency features? Will the topic still be explored in the Swift 4 timeframe, or do you expect that discussion be deferred to 5 or beyond?
Dan
···
On May 16, 2016, at 8:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hi Everyone,
As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up to be. Ted posted details of the Swift 3 release process last week (https://swift.org/blog/swift-3-0-release-process/\) and I just updated the main swift-evolution README.md file (https://github.com/apple/swift-evolution\) with some updated details about the goals of Swift 3.
This release is shaping up to be a really phenomenal release that will redefine the feel of Swift and make a major leap towards maturing the Swift language and development experience. We have had a focus on getting to source stability, with the forward-looking goal of making Swift 4 as source compatible with Swift 3 as we can reasonably accomplish. It tackled API naming head on (which is one of the hardest problems in computer science [1]), made major improvements to the consistency and feel of the language, and has several nice across the board additions.
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
I expect discussion and planning for Swift 3.x and Swift 4 to start sometime around August of this year. Until then, it is very important that we as a community stay focused on the goals of Swift 3: I’d really prefer us all to resist the urge to discuss major blue sky features for future releases. We would also like to put a significant amount of effort into bug fixing and quality refinements as well, which means that the core team will be proactively deferring evolution proposals to later releases that don’t align with the Swift 3 goals, especially those that are strictly additive.
Thank you for all of the amazing community that has developed on this list, it is great to work with you all! Let us know if you have any questions,
-Chris
[1] It is well known that the two hard problems in Computer Science are naming, cache invalidation, and off-by-one errors.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
As we get deeper into the Swift 3 release cycle, we’re beginning to have
a more precise understanding about what the release will shape up to be.
Ted posted details of the Swift 3 release process last week
(https://swift.org/blog/swift-3-0-release-process/\) and I just updated
the main swift-evolution README.md file
(https://github.com/apple/swift-evolution\) with some updated details
about the goals of Swift 3.
I noticed this comment on Hacker News:
The comment brought up a question about the "Portability" section
disappearing from the README. Until reading that comment I had not
noticed the removal of the goal. But upon examination I would like to
know what the implication of that removal is.
Would you mind expanding on the implications of that section
disappearing? Just an accidental omission? Is portability now considered
done/achieved? Or are the core team members throwing in the towel on
that goal? (Perhaps it is some variation on those themes or something
completely different)
···
On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution wrote:
This release is shaping up to be a really phenomenal release that will
redefine the feel of Swift and make a major leap towards maturing the
Swift language and development experience. We have had a focus on
getting to source stability, with the forward-looking goal of making
Swift 4 as source compatible with Swift 3 as we can reasonably
accomplish. It tackled API naming head on (which is one of the hardest
problems in computer science [1]), made major improvements to the
consistency and feel of the language, and has several nice across the
board additions.
That said, it is also clear at this point that some of the loftier goals
that we started out with aren’t going to fit into the release - including
some of the most important generics features needed in order to lock down
the ABI of the standard library. As such, the generics and ABI stability
goals will roll into a future release of Swift, where I expect them to be
the *highest* priority features to get done.
I expect discussion and planning for Swift 3.x and Swift 4 to start
sometime around August of this year. Until then, it is very important
that we as a community stay focused on the goals of Swift 3: I’d really
prefer us all to resist the urge to discuss major blue sky features for
future releases. We would also like to put a significant amount of
effort into bug fixing and quality refinements as well, which means that
the core team will be proactively deferring evolution proposals to later
releases that don’t align with the Swift 3 goals, especially those that
are strictly additive.
Thank you for all of the amazing community that has developed on this
list, it is great to work with you all! Let us know if you have any
questions,
-Chris
[1] It is well known that the two hard problems in Computer Science are
naming, cache invalidation, and off-by-one errors.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I'm curious, has the Swift team considered not having a public stable ABI for Swift at all, and instead only define some kind of versioned low-level bitcode for packaging purposes which then would be compiled and linked by a system/package repository/App Store service?
This would allow the ABI to evolve with the compiler and would provide more flexibility for e.g. the compilation of generic code and the implementation of shared libraries.
- Stephan
···
On 2016-05-16, Chris Lattner via swift-evolution wrote:
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
The highest priority to me is to get the “little syntactic stuff” done that we want to nail down because it affects source stability. A recent thing that came up was @noescape -> @nonescaping and whether to make it the default, for example.
As for dropping, it is pretty clear that we are out of time for large-scope additions.
-Chris
···
On May 16, 2016, at 9:29 AM, David Sweeris <davesweeris@mac.com> wrote:
On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
Oh, good! I was getting worried about that. Are there any particular topics that we should drop or discuss?
Portability is still a strong goal, I will add it back, thank you for raising this!
-Chris
···
On May 16, 2016, at 11:53 AM, Ryan Lovelett <swift-dev@ryan.lovelett.me> wrote:
On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution > wrote:
Hi Everyone,
As we get deeper into the Swift 3 release cycle, we’re beginning to have
a more precise understanding about what the release will shape up to be.
Ted posted details of the Swift 3 release process last week
(https://swift.org/blog/swift-3-0-release-process/\) and I just updated
the main swift-evolution README.md file
(https://github.com/apple/swift-evolution\) with some updated details
about the goals of Swift 3.
The comment brought up a question about the "Portability" section
disappearing from the README. Until reading that comment I had not
noticed the removal of the goal. But upon examination I would like to
know what the implication of that removal is.
Would you mind expanding on the implications of that section
disappearing? Just an accidental omission? Is portability now considered
done/achieved? Or are the core team members throwing in the towel on
that goal? (Perhaps it is some variation on those themes or something
completely different)
I expect us to discuss what goes into post-Swift-3.0 release in ~August this year. I’m sure that many folks will be interested in this and many other topics.
-Chris
···
On May 16, 2016, at 12:29 PM, Dan Stenmark <daniel.j.stenmark@gmail.com> wrote:
With the generics and ABI stability goals getting pushed out to a future release, how does that affect the plans for Swift concurrency features? Will the topic still be explored in the Swift 4 timeframe, or do you expect that discussion be deferred to 5 or beyond?
Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0?
···
Sent from my iPhone
On 16 May 2016, at 17:43, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 16, 2016, at 9:29 AM, David Sweeris <davesweeris@mac.com> wrote:
On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
Oh, good! I was getting worried about that. Are there any particular topics that we should drop or discuss?
The highest priority to me is to get the “little syntactic stuff” done that we want to nail down because it affects source stability. A recent thing that came up was @noescape -> @nonescaping and whether to make it the default, for example.
As for dropping, it is pretty clear that we are out of time for large-scope additions.
Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0?
We’ll start discussing post-3.0 releases in August. Until Swift 3 is really wound down, it is almost impossible to make forward looking plans.
-Chris
···
On May 16, 2016, at 10:38 AM, Goffredo Marocchi <panajev@gmail.com> wrote:
Sent from my iPhone
On 16 May 2016, at 17:43, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 16, 2016, at 9:29 AM, David Sweeris <davesweeris@mac.com> wrote:
On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the *highest* priority features to get done.
Oh, good! I was getting worried about that. Are there any particular topics that we should drop or discuss?
The highest priority to me is to get the “little syntactic stuff” done that we want to nail down because it affects source stability. A recent thing that came up was @noescape -> @nonescaping and whether to make it the default, for example.
As for dropping, it is pretty clear that we are out of time for large-scope additions.
At what point would you consider the Linux product to be viable for
production server side application development. Do you think that goal has
been achieved in swift 3.0. Or is it going to have to wait for the ABI lock
down.
I'm weighting the wisdom of possibly using Swift on linux for
microservices, we are comming from a modernPHP and OOP environment, and
many of the alternatives such as go and rust have higher impedance
mismatches than swift, given the skills I have available in the
organisation.
I'm interested in cross platform app development down the line, but for
now, I'm only really interested in building out APIs with it.
···
On 17 May 2016 02:14, "Chris Lattner via swift-evolution" < swift-evolution@swift.org> wrote:
On May 16, 2016, at 10:38 AM, Goffredo Marocchi <panajev@gmail.com> wrote:
> Quite sad we could not get into ABI stability for Swift 3... but are we
talking Swift 3.1 or 4.0?
We’ll start discussing post-3.0 releases in August. Until Swift 3 is
really wound down, it is almost impossible to make forward looking plans.
-Chris
>
> Sent from my iPhone
>
>> On 16 May 2016, at 17:43, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>>
>>> On May 16, 2016, at 9:29 AM, David Sweeris <davesweeris@mac.com> > wrote:
>>>
>>>
>>>> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>>>
>>>> That said, it is also clear at this point that some of the loftier
goals that we started out with aren’t going to fit into the release -
including some of the most important generics features needed in order to
lock down the ABI of the standard library. As such, the generics and ABI
stability goals will roll into a future release of Swift, where I expect
them to be the *highest* priority features to get done.
>>>
>>> Oh, good! I was getting worried about that. Are there any particular
topics that we should drop or discuss?
>>
>> The highest priority to me is to get the “little syntactic stuff” done
that we want to nail down because it affects source stability. A recent
thing that came up was @noescape -> @nonescaping and whether to make it the
default, for example.
>>
>> As for dropping, it is pretty clear that we are out of time for
large-scope additions.
>>
>> -Chris
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0?
Disappointing is my first thought, in fact worrying. Two years after the language was announced, the ABI is still not stable.
Of the original Swift 3 goals, it looks like many will not be met. There were seven goals and only two are still in the Readme file[1]. On the assumption that the other five were all dropped because they will not be achieved in Swift 3, this looks like failure.
I’ve been following the evolution list on and off since it started and it hasn’t felt like failure. In fact, it felt like important progress has been made and the language will be hugely better for it, but I do hope that the development team does take the opportunity to review the release in light of the original goals to see if there are any opportunities to improve the development process for the next release.
I'm not an expert in the Linux communities needs and desires. That said, from what I understand, they don’t care at all about ABI stability, since everything is typically built from source.
-Chris
···
On May 16, 2016, at 11:33 AM, Tim Hawkins <tim.thawkins@gmail.com> wrote:
At what point would you consider the Linux product to be viable for production server side application development. Do you think that goal has been achieved in swift 3.0. Or is it going to have to wait for the ABI lock down.
I'm not an expert in the Linux communities needs and desires. That said,
from what I understand, they don’t care at all about ABI stability, since
everything is typically built from source.
-Chris
Not exactly true. (I care.)
Video games (e.g. Steam/Linux) care deeply about ABI stability. And
Android cares deeply about ABI stability. Also, kind of emergent
behavior, Raspberry Pi Raspbian has kind of built a platform that
happens to have some ABI stability for now.
I think it would be more appropriate to say that the server development community generally doesn't care deeply about ABI stability (although even there I'm sure there are exceptions). There are a lot of client-side efforts that have very different requirements from that, though.
John.
···
On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 16, 2016, at 11:33 AM, Tim Hawkins <tim.thawkins@gmail.com <mailto:tim.thawkins@gmail.com>> wrote:
At what point would you consider the Linux product to be viable for production server side application development. Do you think that goal has been achieved in swift 3.0. Or is it going to have to wait for the ABI lock down.
I'm not an expert in the Linux communities needs and desires. That said, from what I understand, they don’t care at all about ABI stability, since everything is typically built from source.
Our ABI considerations are also undeniably going to be Apple-focused. Anyone serious about building a client-side Swift platform on Linux should probably vet our decisions to ensure they make sense for their purposes too.
-Joe
···
On May 16, 2016, at 2:53 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 16, 2016, at 11:33 AM, Tim Hawkins <tim.thawkins@gmail.com> wrote:
At what point would you consider the Linux product to be viable for production server side application development. Do you think that goal has been achieved in swift 3.0. Or is it going to have to wait for the ABI lock down.
I'm not an expert in the Linux communities needs and desires. That said, from what I understand, they don’t care at all about ABI stability, since everything is typically built from source.
I think it would be more appropriate to say that the server development community generally doesn't care deeply about ABI stability (although even there I'm sure there are exceptions). There are a lot of client-side efforts that have very different requirements from that, though.
ABI stability is also central to eventually removing the need to always ship the runtime along with our binaries.
Charles
···
On May 16, 2016, at 4:27 PM, Eric Wing via swift-evolution <swift-evolution@swift.org> wrote:
I'm not an expert in the Linux communities needs and desires. That said,
from what I understand, they don’t care at all about ABI stability, since
everything is typically built from source.
-Chris
Not exactly true. (I care.)
Video games (e.g. Steam/Linux) care deeply about ABI stability. And
Android cares deeply about ABI stability. Also, kind of emergent
behavior, Raspberry Pi Raspbian has kind of built a platform that
happens to have some ABI stability for now.
Great to know, and good point. From that perspective, a Steam/Linux project would be in the same category as an iOS or Mac app: ABI stability doesn’t matter, so long as you include a copy of the swift standard library along with the steam app itself. I know nothing about Steam, but it seems likely that this would have been a requirement anyway, because you can’t count on the standard library already existing.
ABI stability starts to matter when you’re interested in combining precompiled libraries built by different parties, which are only distributed in binary form.
-Chris
···
On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution <swift-evolution@swift.org> wrote:
I'm not an expert in the Linux communities needs and desires. That said,
from what I understand, they don’t care at all about ABI stability, since
everything is typically built from source.
Not exactly true. (I care.)
Video games (e.g. Steam/Linux) care deeply about ABI stability. And
Android cares deeply about ABI stability. Also, kind of emergent
behavior, Raspberry Pi Raspbian has kind of built a platform that
happens to have some ABI stability for now.
I'm not an expert in the Linux communities needs and desires. That
said,
from what I understand, they don’t care at all about ABI stability,
since
everything is typically built from source.
Not exactly true. (I care.)
Video games (e.g. Steam/Linux) care deeply about ABI stability. And
Android cares deeply about ABI stability. Also, kind of emergent
behavior, Raspberry Pi Raspbian has kind of built a platform that
happens to have some ABI stability for now.
Great to know, and good point. From that perspective, a Steam/Linux project
would be in the same category as an iOS or Mac app: ABI stability doesn’t
matter, so long as you include a copy of the swift standard library along
with the steam app itself. I know nothing about Steam, but it seems likely
that this would have been a requirement anyway, because you can’t count on
the standard library already existing.
Yes. I actually filed some bug reports a few weeks ago for
thoughts/concerns/issues related to this.
ABI stability starts to matter when you’re interested in combining
precompiled libraries built by different parties, which are only distributed
in binary form.
That is what I’m working on. I also care about Mac and iOS.
Thanks,
Eric
···
On 5/16/16, Chris Lattner <clattner@apple.com> wrote:
On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution > <swift-evolution@swift.org> wrote:
I'm speaking for myself here but I'm already working independent projects in Linux here. The only missing feature to my current needs it's the implementation of NSBundle methods like load(). Any idea when we'll get those implemented?
- Leonardo
···
-----Original Message-----
From: "Chris Lattner via swift-evolution" <swift-evolution@swift.org>
Sent: 16/05/2016 06:07 PM
To: "Tim Hawkins" <tim.thawkins@gmail.com>
Cc: "Tino Heth via swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Winding down the Swift 3 release
On May 16, 2016, at 11:33 AM, Tim Hawkins <tim.thawkins@gmail.com> wrote:
At what point would you consider the Linux product to be viable for production server side application development. Do you think that goal has been achieved in swift 3.0. Or is it going to have to wait for the ABI lock down.
I'm not an expert in the Linux communities needs and desires. That said, from what I understand, they don’t care at all about ABI stability, since everything is typically built from source.