<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div> <br> <div id="bloop_sign_1502213326961279744" class="bloop_sign"></div> <br><p class="airmail_on">Am 8. August 2017 um 18:24:25, Ted Kremenek via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div></div><div>
<title></title>
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi everyone,
<div class=""><br class=""></div>
<div class="">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!</div>
<div class=""><br class=""></div>
<div class="">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:</div>
<div class=""><br class=""></div>
<div class=""> <a href="https://github.com/apple/swift-evolution" class="">https://github.com/apple/swift-evolution</a></div>
<div class=""><br class=""></div>
<div class="">and a more persistent URL (invariant to future
README.md changes):</div>
<div class=""><br class=""></div>
<div class=""> <a href="https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md" class="">https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md</a></div>
<div class=""><br class=""></div>
<div class="">I am not going to repeat all of that information
here, but I wanted to highlight a few important things.</div>
<div class=""><br class=""></div>
<div class="">## ABI Stability</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">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:</div>
<div class=""><br class=""></div>
<div class=""> <a href="https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md" class="">https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md</a></div>
<div class=""><br class=""></div>
<div class="">Module stability is a stretch goal for Swift 5, but
even without module stability we can still achieve the primary
value of ABI stability.</div>
<div class=""><br class=""></div>
<div class="">## Other focus areas (including laying the
groundwork for concurrency)</div>
<div class=""><br class=""></div>
<div class="">
<div class="">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.</div>
</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">## Changes to the language evolution process</div>
<div class=""><br class=""></div>
<div class="">Last, I want to highlight important changes to the
evolution process:</div>
<div class=""><br class=""></div>
<div class=""> <a href="https://github.com/apple/swift-evolution" class="">https://github.com/apple/swift-evolution</a><a href="https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5" class="">#evolution-process-for-swift-5</a></div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">There are two key benefits of requiring an
implementation:</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">2. An implementation allows the proposal to be
evaluated on real world code and not just the examples that are in
the proposal.</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">- Ted</div>
</div>
</div>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>