[swift-evolution] Swift 5: start your engines

[Wallacy]

My 2c:

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

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 at 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:
>
>   https://github.com/apple/swift-evolution
>
> 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:
>
>   https://github.com/apple/swift-evolution#evolution-process-for-swift-5
> <https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5>
>
> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170809/486125df/attachment-0001.html>