Swift 5: start your engines

Evolution Announcements
1

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted updates to the README.md file on the swift-evolution repository, which outlines the core themes and focus areas for Swift 5:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

  swift-evolution/README.md at 9cc90f33b6659adeaf92355c359e34e6fed73254 · apple/swift-evolution · GitHub

I am not going to repeat all of that information here, but I wanted to highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a *requirement* of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module stability. If you are not aware of the difference — which is rather important — please read the first few paragraphs of the ABI stability manifesto:

  swift/ABIStabilityManifesto.md at main · apple/swift · GitHub

Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. <https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5&gt;

With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release. This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability. One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release. Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects. Related, there has been some desire for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal. After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by **requiring that all proposals have an implementation** before they are officially reviewed by the Core Team. An implementation can come long after an idea has been pitched and after a proposal has been written. However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review. The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed. The hope is that this will make the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in providing an implementation for a proposal that is not likely to get traction. The Core Team will be regularly reviewing potential proposals, and provide feedback either during the pitch stage or when a proposal is submitted via a pull request on whether or not the proposed change looks within the charter of the release or meets the criteria for a valuable change to the language.

Requiring an implementation naturally raises the bar for proposals. While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process. As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals. Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of scope for proposals considered for Swift 5 begins… now! Proposals that fit within the general focus of the release are welcome until March 1, 2018. Proposals will still be considered after that, but the bar will be increasingly high to accept changes for Swift 5.

- Ted

1 Like
2

Thank you for the kind updates Ted. However I already feel the negative impact because of the last restriction. I also would like to point out that, personally I think until the swift-evolution is not moved to a forum this will only create a great wall between proposal authors and people that are capable of implementing the pitched functionality. However I see your point there, I’ve also seen Slava Pestov pointing this out a couple of times before, and I fully understand the main idea behind it. However, my main point is that it would be really hard now to find volunteers who can implement new functionality before we can even review something. For instance we’ve got a quite complex proposal that didn’t made it in to Swift 3 in time and was deferred from Swift 4, which aimed to fix metatypes in Swift. I can only speak for myself and not the other two authors of our proposal, but I won’t be able to provide an implementation for that proposal, because I’m not a complier engineer and probably won’t become one any time soon. Long story short the last restriction makes it really hard for me to participate in swift-evolution process except for providing feedback in active reviews.

···

Am 8. August 2017 um 18:24:25, Ted Kremenek via swift-evolution (swift-evolution@swift.org) schrieb:

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted updates to the README.md file on the swift-evolution repository, which outlines the core themes and focus areas for Swift 5:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

swift-evolution/README.md at 9cc90f33b6659adeaf92355c359e34e6fed73254 · apple/swift-evolution · GitHub

I am not going to repeat all of that information here, but I wanted to highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a *requirement* of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module stability. If you are not aware of the difference — which is rather important — please read the first few paragraphs of the ABI stability manifesto:

swift/ABIStabilityManifesto.md at main · apple/swift · GitHub

Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release. This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability. One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release. Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects. Related, there has been some desire for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal. After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by **requiring that all proposals have an implementation** before they are officially reviewed by the Core Team. An implementation can come long after an idea has been pitched and after a proposal has been written. However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review. The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed. The hope is that this will make the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in providing an implementation for a proposal that is not likely to get traction. The Core Team will be regularly reviewing potential proposals, and provide feedback either during the pitch stage or when a proposal is submitted via a pull request on whether or not the proposed change looks within the charter of the release or meets the criteria for a valuable change to the language.

Requiring an implementation naturally raises the bar for proposals. While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process. As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals. Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of scope for proposals considered for Swift 5 begins… now! Proposals that fit within the general focus of the release are welcome until March 1, 2018. Proposals will still be considered after that, but the bar will be increasingly high to accept changes for Swift 5.

- Ted
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

is it accept proposal for coroutine?
Just like the one i had proposed before:

···

2017-08-09 0:23 GMT+08:00 Ted Kremenek via swift-evolution < swift-evolution@swift.org>:

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is
now in endgame engineering convergence for an expected release later this
year. Swift 4 has turned out to be one of the highest quality,
well-rounded releases of Swift, and I am grateful to everyone in the
community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted
updates to the README.md file on the swift-evolution repository, which
outlines the core themes and focus areas for Swift 5:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

  https://github.com/apple/swift-evolution/blob/
9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to
highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot
much of our prioritization of efforts for Swift 5 around it. With Swift 4,
ABI stability was a strong goal. In Swift 5, it is a *requirement* of the
release. Whatever ABI we have at the end of Swift 5 is the ABI that we
will have. ABI stability is an important inflection point for the maturity
of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module
stability. If you are not aware of the difference — which is rather
important — please read the first few paragraphs of the ABI stability
manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module
stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat
here, but there is a general theme of refining and broadening out the core
ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for
concurrency. It is a non-goal of Swift 5 to roll out a full new
concurrency model. That is simply too large an effort to do alongside ABI
stability. However, it is important that we start making progress on
discussing the directions for concurrency and laying some of the
groundwork. This may take the form of specific enhancements to the
language that get implemented, depending on where the discussions for
concurrency lead and how they align with the priorities for delivering ABI
stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
<https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5&gt;

With Swift 4, the release period was divided up into “stage 1” and “stage
2” for setting guidelines for the kind of evolution proposals that were in
scope for the release. This was needed to establish focus — especially
after the churn we saw during Swift 3 — on some core themes that were
aligned with converging the language towards source & ABI stability. One
downside is that “stage 2” opened up discussion for potentially disruptive
changes fairly late in the release. Further, some proposals — such as
SE-0155 — came in so late that there was little runway to actually
implement them for Swift 4, let alone evaluate their impact in practice on
real projects. Related, there has been some desire for a while to be able
to better evaluate the impact of proposals on real code before they are
locked into the release, and the best way to do that is to actually have an
implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for
both design and implementation work, but the Core Team did not want that
focus to stifle all discussion on potential enhancements to the language
that were not fundamentally tied to that primary goal. After reflecting on
the evolution process during both the Swift 3 and Swift 4 releases, the
Core Team felt that we could strike a balance with not diluting attention
from ABI stability while still enabling a broader range of proposals
compared to Swift 4 by **requiring that all proposals have an
implementation** before they are officially reviewed by the Core Team. An
implementation can come long after an idea has been pitched and after a
proposal has been written. However, before a pull request for an evolution
proposal will be accepted — and thus an official review scheduled — an
implementation must be in hand for a proposal as part of the review. The
existence of an implementation does not guarantee that the proposal will
be accepted, but it is instrumental in evaluating the quality and impact of
the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out
before the proposal is formally reviewed. The hope is that this will make
the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world
code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in
providing an implementation for a proposal that is not likely to get
traction. The Core Team will be regularly reviewing potential proposals,
and provide feedback either during the pitch stage or when a proposal is
submitted via a pull request on whether or not the proposed change looks
within the charter of the release or meets the criteria for a valuable
change to the language.

Requiring an implementation naturally raises the bar for proposals. While
this is by design, it can possibly have the negative aspect of making some
feel the bar is too high for them to participate in the Swift evolution
process. As an open source project, both the design and implementation of
the language is a highly social endeavor, and we encourage the community to
collaborate on both the design and implementation of proposals.
Specifically, it is not a requirement that the original author(s) of a
proposal be the one who provides an implementation — all that matters is
that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of
scope for proposals considered for Swift 5 begins… now! Proposals that fit
within the general focus of the release are welcome until March 1, 2018.
Proposals will still be considered after that, but the bar will
be increasingly high to accept changes for Swift 5.

- Ted

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

My 2c:

Revisit: SE-0030 Property Behaviors
<https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md&gt;

Very cool feature, and will help implement new thinks after that! Including
async and await maybe!

···

Em ter, 8 de ago de 2017 às 13:23, Ted Kremenek via swift-evolution < swift-evolution@swift.org> escreveu:

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is
now in endgame engineering convergence for an expected release later this
year. Swift 4 has turned out to be one of the highest quality,
well-rounded releases of Swift, and I am grateful to everyone in the
community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted
updates to the README.md file on the swift-evolution repository, which
outlines the core themes and focus areas for Swift 5:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to
highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot
much of our prioritization of efforts for Swift 5 around it. With Swift 4,
ABI stability was a strong goal. In Swift 5, it is a *requirement* of the
release. Whatever ABI we have at the end of Swift 5 is the ABI that we
will have. ABI stability is an important inflection point for the maturity
of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module
stability. If you are not aware of the difference — which is rather
important — please read the first few paragraphs of the ABI stability
manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module
stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat
here, but there is a general theme of refining and broadening out the core
ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for
concurrency. It is a non-goal of Swift 5 to roll out a full new
concurrency model. That is simply too large an effort to do alongside ABI
stability. However, it is important that we start making progress on
discussing the directions for concurrency and laying some of the
groundwork. This may take the form of specific enhancements to the
language that get implemented, depending on where the discussions for
concurrency lead and how they align with the priorities for delivering ABI
stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
<https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5&gt;

With Swift 4, the release period was divided up into “stage 1” and “stage
2” for setting guidelines for the kind of evolution proposals that were in
scope for the release. This was needed to establish focus — especially
after the churn we saw during Swift 3 — on some core themes that were
aligned with converging the language towards source & ABI stability. One
downside is that “stage 2” opened up discussion for potentially disruptive
changes fairly late in the release. Further, some proposals — such as
SE-0155 — came in so late that there was little runway to actually
implement them for Swift 4, let alone evaluate their impact in practice on
real projects. Related, there has been some desire for a while to be able
to better evaluate the impact of proposals on real code before they are
locked into the release, and the best way to do that is to actually have an
implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for
both design and implementation work, but the Core Team did not want that
focus to stifle all discussion on potential enhancements to the language
that were not fundamentally tied to that primary goal. After reflecting on
the evolution process during both the Swift 3 and Swift 4 releases, the
Core Team felt that we could strike a balance with not diluting attention
from ABI stability while still enabling a broader range of proposals
compared to Swift 4 by **requiring that all proposals have an
implementation** before they are officially reviewed by the Core Team. An
implementation can come long after an idea has been pitched and after a
proposal has been written. However, before a pull request for an evolution
proposal will be accepted — and thus an official review scheduled — an
implementation must be in hand for a proposal as part of the review. The
existence of an implementation does not guarantee that the proposal will
be accepted, but it is instrumental in evaluating the quality and impact of
the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out
before the proposal is formally reviewed. The hope is that this will make
the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world
code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in
providing an implementation for a proposal that is not likely to get
traction. The Core Team will be regularly reviewing potential proposals,
and provide feedback either during the pitch stage or when a proposal is
submitted via a pull request on whether or not the proposed change looks
within the charter of the release or meets the criteria for a valuable
change to the language.

Requiring an implementation naturally raises the bar for proposals. While
this is by design, it can possibly have the negative aspect of making some
feel the bar is too high for them to participate in the Swift evolution
process. As an open source project, both the design and implementation of
the language is a highly social endeavor, and we encourage the community to
collaborate on both the design and implementation of proposals.
Specifically, it is not a requirement that the original author(s) of a
proposal be the one who provides an implementation — all that matters is
that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of
scope for proposals considered for Swift 5 begins… now! Proposals that fit
within the general focus of the release are welcome until March 1, 2018.
Proposals will still be considered after that, but the bar will
be increasingly high to accept changes for Swift 5.

- Ted
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

I am not against these changes, of requiring an implementation, but I am a
little nervous. Let me expand.

I was involved in the Java Coin initiative for community driven changes to
Java 7. In that process the implementation barrier was set very high and it
effectively meant that only changes from Sun got through, a number of
people put considerable effort in only for the proposals to be rejected. I
felt the process was in the end a little disingenuous and I think that view
was held by many, perhaps tellingly the process has never run again for
subsequent Java versions.

So my cautionary note is that this requirement of implementation requires
careful stewardship and in particular there needs to be some means of
getting 'in principle' approval before the implementation stage. If done
correctly it could work very well.

  -- Howard.

···

On 9 August 2017 at 02:23, Ted Kremenek <kremenek@apple.com> wrote:

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is
now in endgame engineering convergence for an expected release later this
year. Swift 4 has turned out to be one of the highest quality,
well-rounded releases of Swift, and I am grateful to everyone in the
community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted
updates to the README.md file on the swift-evolution repository, which
outlines the core themes and focus areas for Swift 5:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

  https://github.com/apple/swift-evolution/blob/
9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to
highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot
much of our prioritization of efforts for Swift 5 around it. With Swift 4,
ABI stability was a strong goal. In Swift 5, it is a *requirement* of the
release. Whatever ABI we have at the end of Swift 5 is the ABI that we
will have. ABI stability is an important inflection point for the maturity
of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module
stability. If you are not aware of the difference — which is rather
important — please read the first few paragraphs of the ABI stability
manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module
stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat
here, but there is a general theme of refining and broadening out the core
ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for
concurrency. It is a non-goal of Swift 5 to roll out a full new
concurrency model. That is simply too large an effort to do alongside ABI
stability. However, it is important that we start making progress on
discussing the directions for concurrency and laying some of the
groundwork. This may take the form of specific enhancements to the
language that get implemented, depending on where the discussions for
concurrency lead and how they align with the priorities for delivering ABI
stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
<https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5&gt;

With Swift 4, the release period was divided up into “stage 1” and “stage
2” for setting guidelines for the kind of evolution proposals that were in
scope for the release. This was needed to establish focus — especially
after the churn we saw during Swift 3 — on some core themes that were
aligned with converging the language towards source & ABI stability. One
downside is that “stage 2” opened up discussion for potentially disruptive
changes fairly late in the release. Further, some proposals — such as
SE-0155 — came in so late that there was little runway to actually
implement them for Swift 4, let alone evaluate their impact in practice on
real projects. Related, there has been some desire for a while to be able
to better evaluate the impact of proposals on real code before they are
locked into the release, and the best way to do that is to actually have an
implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for
both design and implementation work, but the Core Team did not want that
focus to stifle all discussion on potential enhancements to the language
that were not fundamentally tied to that primary goal. After reflecting on
the evolution process during both the Swift 3 and Swift 4 releases, the
Core Team felt that we could strike a balance with not diluting attention
from ABI stability while still enabling a broader range of proposals
compared to Swift 4 by **requiring that all proposals have an
implementation** before they are officially reviewed by the Core Team. An
implementation can come long after an idea has been pitched and after a
proposal has been written. However, before a pull request for an evolution
proposal will be accepted — and thus an official review scheduled — an
implementation must be in hand for a proposal as part of the review. The
existence of an implementation does not guarantee that the proposal will
be accepted, but it is instrumental in evaluating the quality and impact of
the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out
before the proposal is formally reviewed. The hope is that this will make
the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world
code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in
providing an implementation for a proposal that is not likely to get
traction. The Core Team will be regularly reviewing potential proposals,
and provide feedback either during the pitch stage or when a proposal is
submitted via a pull request on whether or not the proposed change looks
within the charter of the release or meets the criteria for a valuable
change to the language.

Requiring an implementation naturally raises the bar for proposals. While
this is by design, it can possibly have the negative aspect of making some
feel the bar is too high for them to participate in the Swift evolution
process. As an open source project, both the design and implementation of
the language is a highly social endeavor, and we encourage the community to
collaborate on both the design and implementation of proposals.
Specifically, it is not a requirement that the original author(s) of a
proposal be the one who provides an implementation — all that matters is
that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of
scope for proposals considered for Swift 5 begins… now! Proposals that fit
within the general focus of the release are welcome until March 1, 2018.
Proposals will still be considered after that, but the bar will
be increasingly high to accept changes for Swift 5.

- Ted

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

6

This change is also intended to strengthen the community in two other ways:

1) a person or organization sufficiently motivated and able to push an effort forward can now do it, even if it is outside the scope of Apple’s current priorities.

2) it encourages more folks to get involved in implementation tasks, by providing an incentive to do so.

Hopefully both of these will lead to a broader and stronger Swift community.

-Chris

···

On Aug 8, 2017, at 3:06 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

From what I know of the team, they’re not going to let a good idea languish just because of the name that’s in the author field. I’m sure they _are_ going to strategically prioritize what gets attention, and that’s not a bad thing.

Perhaps I'm being overly optimistic but I see this change as enhancing collaboration between idea-level and code-level evolution. Requiring a preliminary implementation:

7

Perhaps I'm being overly optimistic but I see this change as enhancing collaboration between idea-level and code-level evolution. Requiring a preliminary implementation:

Ensures a proof of concept that the proposed change (like expanding `Self` to classes) is realistic and possible.
Ensures that the Swift codebase impact can be measured at the time the proposal is evaluated.
Encourages multi-author proposal teams, comprised of people who understand code impact as well those who can express the importance of the language expression from a user side.
Provides real world "road testing" of proposed toolchain enhancements, letting the changes be "tuned" before proposal. This minimizes adoption regrets, because the beta toolchain can be used with real code. (As with the tuples and closures)
Upfront costs *will* be higher. Not only do you have to believe that a change is good, you must develop a working group that includes coders to create a prototype without any guarantee that the change will pass muster.

Finding those coders and convincing them this will be a great change means that proposals will naturally skew towards Apple-driven rather than wider community-driven. However it does not exclude the latter, especially for passionate proposals that can find the coders to champion them.

-- Erica

···

On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:

Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but…

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

From what I know of the team, they’re not going to let a good idea languish just because of the name that’s in the author field. I’m sure they _are_ going to strategically prioritize what gets attention, and that’s not a bad thing.

Cheers,

Paul

8

Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but…

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

From what I know of the team, they’re not going to let a good idea languish just because of the name that’s in the author field. I’m sure they _are_ going to strategically prioritize what gets attention, and that’s not a bad thing.

Cheers,

Paul

···

On Aug 8, 2017, at 12:40 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Thank you for the kind updates Ted. However I already feel the negative impact because of the last restriction. I also would like to point out that, personally I think until the swift-evolution is not moved to a forum this will only create a great wall between proposal authors and people that are capable of implementing the pitched functionality. However I see your point there, I’ve also seen Slava Pestov pointing this out a couple of times before, and I fully understand the main idea behind it. However, my main point is that it would be really hard now to find volunteers who can implement new functionality before we can even review something. For instance we’ve got a quite complex proposal that didn’t made it in to Swift 3 in time and was deferred from Swift 4, which aimed to fix metatypes in Swift. I can only speak for myself and not the other two authors of our proposal, but I won’t be able to provide an implementation for that proposal, because I’m not a complier engineer and probably won’t become one any time soon. Long story short the last restriction makes it really hard for me to participate in swift-evolution process except for providing feedback in active reviews.

Am 8. August 2017 um 18:24:25, Ted Kremenek via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted updates to the README.md file on the swift-evolution repository, which outlines the core themes and focus areas for Swift 5:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

  https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a *requirement* of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module stability. If you are not aware of the difference — which is rather important — please read the first few paragraphs of the ABI stability manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. <https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5&gt;

With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release. This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability. One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release. Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects. Related, there has been some desire for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal. After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by **requiring that all proposals have an implementation** before they are officially reviewed by the Core Team. An implementation can come long after an idea has been pitched and after a proposal has been written. However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review. The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed. The hope is that this will make the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in providing an implementation for a proposal that is not likely to get traction. The Core Team will be regularly reviewing potential proposals, and provide feedback either during the pitch stage or when a proposal is submitted via a pull request on whether or not the proposed change looks within the charter of the release or meets the criteria for a valuable change to the language.

Requiring an implementation naturally raises the bar for proposals. While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process. As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals. Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of scope for proposals considered for Swift 5 begins… now! Proposals that fit within the general focus of the release are welcome until March 1, 2018. Proposals will still be considered after that, but the bar will be increasingly high to accept changes for Swift 5.

- Ted
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

9

I think this very nicely summarizes the intent here. Having a proof of concept will increase the quality of proposals on many levels. Myself and others in the Core Team also hope it will help strengthen the community in the ways Chris mentions — specifically encouraging folks to be get more involved on the implementation of the language and feeling a sense of ownership on driving a proposal from idea to implementation. A natural consequence is that the proposals in the fullness of time will be balanced from different voices in the community, and less so from just the ones the current primary implementers have the capacity to implement.

···

On Aug 8, 2017, at 3:06 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but…

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

From what I know of the team, they’re not going to let a good idea languish just because of the name that’s in the author field. I’m sure they _are_ going to strategically prioritize what gets attention, and that’s not a bad thing.

Cheers,

Paul

Perhaps I'm being overly optimistic but I see this change as enhancing collaboration between idea-level and code-level evolution. Requiring a preliminary implementation:

Ensures a proof of concept that the proposed change (like expanding `Self` to classes) is realistic and possible.
Ensures that the Swift codebase impact can be measured at the time the proposal is evaluated.
Encourages multi-author proposal teams, comprised of people who understand code impact as well those who can express the importance of the language expression from a user side.
Provides real world "road testing" of proposed toolchain enhancements, letting the changes be "tuned" before proposal. This minimizes adoption regrets, because the beta toolchain can be used with real code. (As with the tuples and closures)
Upfront costs *will* be higher. Not only do you have to believe that a change is good, you must develop a working group that includes coders to create a prototype without any guarantee that the change will pass muster.

Finding those coders and convincing them this will be a great change means that proposals will naturally skew towards Apple-driven rather than wider community-driven. However it does not exclude the latter, especially for passionate proposals that can find the coders to champion them.

-- Erica

10

That is true. Everyone’s ability to assist is ultimately balanced by their own capacity and priorities, but I think there are plenty of examples of this happening in the past. Also, there is a increasing number of people — and not just the Core Team or compiler engineers in my team at Apple — who are becoming increasingly comfortable working with the implementation of the compiler and the standard library.

···

On Aug 8, 2017, at 2:29 PM, Paul Cantrell <cantrell@pobox.com> wrote:

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

11

Hi Susan,

I’d love to see progress on this specific topic, with specific application to async/await. I have a much more detailed proposal in the works, I’ll share it when it is ready.

-Chris

···

On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution <swift-evolution@swift.org> wrote:

is it accept proposal for coroutine?
Just like the one i had proposed before: Coroutine for Swift by SusanDoggie · Pull Request #73 · apple/swift-evolution · GitHub

12

Would it be possible to get a series of tutorials on how the systems that make up Swift generally work? In other words, what are the pieces and how do they fit together?

I think it would be useful even for people who aren’t directly implementing because they can have a better idea of how difficult a change actually is. It might also help some of us who have been sitting on the sideline to dip our toes in the water. I know I get a bit lost every time I try to find something in the Swift source, and I am guessing I am not the only one...

Thanks,
Jon

···

On Aug 8, 2017, at 5:27 PM, Ted Kremenek via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 8, 2017, at 2:29 PM, Paul Cantrell <cantrell@pobox.com <mailto:cantrell@pobox.com>> wrote:

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

That is true. Everyone’s ability to assist is ultimately balanced by their own capacity and priorities, but I think there are plenty of examples of this happening in the past. Also, there is a increasing number of people — and not just the Core Team or compiler engineers in my team at Apple — who are becoming increasingly comfortable working with the implementation of the compiler and the standard library.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

I too think this is probably a positive step. I'd also like to point out a couple things (while reminding you that I am *not* on the core team and speak for nobody but myself):

  1. Compiler engineering is not magic. It is *especially* not magic when you're largely dealing with syntax and semantics, rather than code generation. I know it's intimidating, because a year ago I was pretty intimidated by it, but it's basically just programming in a large, complicated project with lots of weird speed hacks. And most of the standard library isn't compiler engineering at all—it's just Swift code written with a weird house style that forbids `private` and `fileprivate`. Anybody who knows enough Swift to express an intelligent opinion on its evolution should know enough to do some standard library work.

  2. We have persistently had too many designs for the available implementers. If we find that this new process overshoots and we now have too many implementers for the available designs, we can change the process again to loosen the "must include an implementation" requirement. (For instance, we might allow simpler testbed or proof-of-concept implementations, like hacky preprocessors or slightly different userspace syntaxes of things that will move into the compiler, when a full implementation would be too difficult to provide ahead of time.)

I do have some concerns about this process. I'm worried that, unless we really firm up the pre-review process, we'll end up wasting a lot of implementation time on stuff that never actually makes it into the language. I'm also worried that we'll end up accepting sub-optimal designs because the alternative is to throw out a lot of work that's already been done and defer a feature to a future version. But again, we can refine the process as we notice its problems. All of these concerns are speculative; the concern that we don't have the implementation bandwidth needed for the current design process is very real.

···

On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Upfront costs *will* be higher. Not only do you have to believe that a change is good, you must develop a working group that includes coders to create a prototype without any guarantee that the change will pass muster.

Finding those coders and convincing them this will be a great change means that proposals will naturally skew towards Apple-driven rather than wider community-driven. However it does not exclude the latter, especially for passionate proposals that can find the coders to champion them.

--
Brent Royal-Gordon
Architechies

14

Async / await is really spoiling me in Node.JS at the moment, you leave with shiver with anticipation!!! :)

···

Sent from my iPhone

On 9 Aug 2017, at 06:41, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution <swift-evolution@swift.org> wrote:

is it accept proposal for coroutine?
Just like the one i had proposed before: Coroutine for Swift by SusanDoggie · Pull Request #73 · apple/swift-evolution · GitHub

Hi Susan,

I’d love to see progress on this specific topic, with specific application to async/await. I have a much more detailed proposal in the works, I’ll share it when it is ready.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

15

Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but…

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

From what I know of the team, they’re not going to let a good idea languish just because of the name that’s in the author field. I’m sure they _are_ going to strategically prioritize what gets attention, and that’s not a bad thing.

Cheers,

Paul

Perhaps I'm being overly optimistic but I see this change as enhancing collaboration between idea-level and code-level evolution. Requiring a preliminary implementation:

Ensures a proof of concept that the proposed change (like expanding `Self` to classes) is realistic and possible.
Ensures that the Swift codebase impact can be measured at the time the proposal is evaluated.
Encourages multi-author proposal teams, comprised of people who understand code impact as well those who can express the importance of the language expression from a user side.
Provides real world "road testing" of proposed toolchain enhancements, letting the changes be "tuned" before proposal. This minimizes adoption regrets, because the beta toolchain can be used with real code. (As with the tuples and closures)

And it will also avoid late changes and new review roundtrip to accepted proposals because we find that some points are ambiguous while implementing it.
And hopefully, it will also decrease the stack of non implemented accepted proposals.

···

Le 9 août 2017 à 00:06, Erica Sadun via swift-evolution <swift-evolution@swift.org> a écrit :

On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Upfront costs *will* be higher. Not only do you have to believe that a change is good, you must develop a working group that includes coders to create a prototype without any guarantee that the change will pass muster.

Finding those coders and convincing them this will be a great change means that proposals will naturally skew towards Apple-driven rather than wider community-driven. However it does not exclude the latter, especially for passionate proposals that can find the coders to champion them.

-- Erica

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

16

I am not against these changes, of requiring an implementation, but I am a little nervous. Let me expand.

I was involved in the Java Coin initiative for community driven changes to Java 7. In that process the implementation barrier was set very high and it effectively meant that only changes from Sun got through, a number of people put considerable effort in only for the proposals to be rejected. I felt the process was in the end a little disingenuous and I think that view was held by many, perhaps tellingly the process has never run again for subsequent Java versions.

So my cautionary note is that this requirement of implementation requires careful stewardship and in particular there needs to be some means of getting 'in principle' approval before the implementation stage. If done correctly it could work very well.

This seems very sensible to me. Certainly we would want some way of flushing out "in principle" concerns before too much implementation time gets spent.

John.

···

On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

  -- Howard.

On 9 August 2017 at 02:23, Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>> wrote:
Hi everyone,

The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!

Now it is time to turn our attention to Swift 5. I have just posted updates to the README.md file on the swift-evolution repository, which outlines the core themes and focus areas for Swift 5:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

and a more persistent URL (invariant to future README.md changes):

  https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md

I am not going to repeat all of that information here, but I wanted to highlight a few important things.

## ABI Stability

First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a *requirement* of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer.

Please note that there is a difference between ABI stability and module stability. If you are not aware of the difference — which is rather important — please read the first few paragraphs of the ABI stability manifesto:

  https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md

Module stability is a stretch goal for Swift 5, but even without module stability we can still achieve the primary value of ABI stability.

## Other focus areas (including laying the groundwork for concurrency)

There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.

One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. This may take the form of specific enhancements to the language that get implemented, depending on where the discussions for concurrency lead and how they align with the priorities for delivering ABI stability in Swift 5.

## Changes to the language evolution process

Last, I want to highlight important changes to the evolution process:

  GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language. <https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5&gt;

With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release. This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability. One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release. Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects. Related, there has been some desire for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.

With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal. After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by **requiring that all proposals have an implementation** before they are officially reviewed by the Core Team. An implementation can come long after an idea has been pitched and after a proposal has been written. However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review. The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.

There are two key benefits of requiring an implementation:

1. It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed. The hope is that this will make the review process both more efficient as well as more effective.

2. An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.

The Core Team is also sensitive to proposal authors investing time in providing an implementation for a proposal that is not likely to get traction. The Core Team will be regularly reviewing potential proposals, and provide feedback either during the pitch stage or when a proposal is submitted via a pull request on whether or not the proposed change looks within the charter of the release or meets the criteria for a valuable change to the language.

Requiring an implementation naturally raises the bar for proposals. While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process. As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals. Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.

Lastly, an important aspect is that unlike Swift 4, the broadening of scope for proposals considered for Swift 5 begins… now! Proposals that fit within the general focus of the release are welcome until March 1, 2018. Proposals will still be considered after that, but the bar will be increasingly high to accept changes for Swift 5.

- Ted

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

17

The project would definitely be well-served by having more documentation, and hopefully we’ll see that grow both incrementally and in spurts. Even writing tutorials, however, must be weighed against competing priorities — such as finishing the work for ABI stability. My hope is we can find a balance of investment in helping more people in the community feel empowered to implement proposals in the compiler/standard library while not diluting focus from delivering ABI stability.

···

On Aug 8, 2017, at 11:28 PM, Jonathan Hull <jhull@gbis.com> wrote:

Would it be possible to get a series of tutorials on how the systems that make up Swift generally work? In other words, what are the pieces and how do they fit together?

I think it would be useful even for people who aren’t directly implementing because they can have a better idea of how difficult a change actually is. It might also help some of us who have been sitting on the sideline to dip our toes in the water. I know I get a bit lost every time I try to find something in the Swift source, and I am guessing I am not the only one...

Thanks,
Jon

On Aug 8, 2017, at 5:27 PM, Ted Kremenek via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Aug 8, 2017, at 2:29 PM, Paul Cantrell <cantrell@pobox.com <mailto:cantrell@pobox.com>> wrote:

I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member.

That is true. Everyone’s ability to assist is ultimately balanced by their own capacity and priorities, but I think there are plenty of examples of this happening in the past. Also, there is a increasing number of people — and not just the Core Team or compiler engineers in my team at Apple — who are becoming increasingly comfortable working with the implementation of the compiler and the standard library.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

18

Upfront costs *will* be higher. Not only do you have to believe that a change is good, you must develop a working group that includes coders to create a prototype without any guarantee that the change will pass muster.

Finding those coders and convincing them this will be a great change means that proposals will naturally skew towards Apple-driven rather than wider community-driven. However it does not exclude the latter, especially for passionate proposals that can find the coders to champion them.

I too think this is probably a positive step. I'd also like to point out a couple things (while reminding you that I am *not* on the core team and speak for nobody but myself):

  1. Compiler engineering is not magic. It is *especially* not magic when you're largely dealing with syntax and semantics, rather than code generation. I know it's intimidating, because a year ago I was pretty intimidated by it, but it's basically just programming in a large, complicated project with lots of weird speed hacks. And most of the standard library isn't compiler engineering at all—it's just Swift code written with a weird house style that forbids `private` and `fileprivate`. Anybody who knows enough Swift to express an intelligent opinion on its evolution should know enough to do some standard library work.

  2. We have persistently had too many designs for the available implementers. If we find that this new process overshoots and we now have too many implementers for the available designs, we can change the process again to loosen the "must include an implementation" requirement. (For instance, we might allow simpler testbed or proof-of-concept implementations, like hacky preprocessors or slightly different userspace syntaxes of things that will move into the compiler, when a full implementation would be too difficult to provide ahead of time.)

I do have some concerns about this process. I'm worried that, unless we really firm up the pre-review process, we'll end up wasting a lot of implementation time on stuff that never actually makes it into the language.

The formal review has always just been a capstone of the real design process, i.e. the process of developing the proposal. Up until now, that capstone has been a lot less meaningful than it could be because there's no choice but to speculate about the actual effects of the change: whether they'll really be able to use it in all the places they think they will, how disruptive a potential source break would be, how much performance the feature actually gains/loses, etc. Some amount of speculation is appropriate — we shouldn't design just for the code that exists today — but there's no replacement for the experience of actually trying to use a feature in code that you're comfortable with.

So today we have this basic development process for proposals:
  1. initial proposal development (often semi-private)
  2. presentation to swift-evolution
  3. iterative open proposal development
  4. formal review, goto 3 until confluence
  5. implementation
  6. feedback from implementation experience, goto 3 until confluence
  7. available in a nightly build or official developer preview
  8. feedback from adopters, goto 3 until confluence
  9. ship it

6 and 8 will always be meaningful sources of feedback with a potential to provoke a revision. We can never completely eliminate the potential for such feedback to arrive after the formal review, because sometimes use or implementation problems only become fully apparent after you've been living with the design for a while. Still, it's somewhat absurd to ask for "final" approval for something that hasn't gone through 6 or 8 at all, and we're seeing the predictable result, where far too many proposals that are going through re-review or requiring follow-up proposals.

The Swift 5 process will hopefully look more like this:
  1. initial proposal development (often semi-private)
  2. presentation to swift-evolution
  3. iterative open proposal development
  5. implementation
  6. feedback from implementation experience, goto 3 until confluence
  7. available for early "adoption" testing as a PR branch, ideally as a special toolchain build
  8. feedback from early "adopters", goto 3 until confluence
  "4". formal review, goto 3 until confluence
  9. ship it

Your role as a proposal author really hasn't substantially changed. It's always been the case that getting something through formal review is no guarantee that it will ever be implemented, so you've never been able to just wash your hands and walk way, and you've always needed to find an implementor. The only thing that's different that we're formally recognizing the importance of having an implementation to evaluating a proposal. That happens to have the nice property that, if the proposal is accepted, it's basically guaranteed to get shipped. But your job as a non-implementing author is still primarily Steps 1-3 and evaluating all the different stages of feedback.

I'm also worried that we'll end up accepting sub-optimal designs because the alternative is to throw out a lot of work that's already been done and defer a feature to a future version.

I'm not worried about this. We've forced significant changes on an implementation before, and we'll do it again. A lot of implementation work has gone into property behaviors, and we still haven't rushed that into production.

John.

···

On Aug 9, 2017, at 2:30 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

But again, we can refine the process as we notice its problems. All of these concerns are speculative; the concern that we don't have the implementation bandwidth needed for the current design process is very real.

19

Slava Pestov wrote a couple of articles last year:

<Medium;

<Medium;

···

On 9 Aug 2017, at 07:29, Jonathan Hull wrote:

Would it be possible to get a series of tutorials on how the systems that make up Swift generally work? In other words, what are the pieces and how do they fit together?