Ted Kremenek just wrote a post detailing Swift 4 stage 2. Here is the
relevant part again [unable to increase the quotation level for unclear
reasons, but the following is a verbatim copy from that message]:
Timeline
Stage 2 starts right now. All design work and discussion for stage 2
extends to *April 1, 2017*. The intent is to timebox discussion to provide
adequate time for the actual implementation of accepted proposals.
Scope
Swift 4 stage 2 builds on the goals of stage 1. It differs in that stage 2
proposals may include some additive changes and changes to existing
features that don't affect the ABI. There are a few focus areas for Swift 4
stage 2:
-
*Stage 1 proposals*: Any proposal that would have been eligible for
stage 1 is a priority for stage 2.
-
*Source-breaking changes*: The Swift 4 compiler will provide a
source-compatibility mode to allow existing Swift 3 sources to compile, but
source-breaking changes can manifest in "Swift 4" mode. That said, changes
to fundamental parts of Swift's syntax or standard library APIs that breaks
source code are better front-loaded into Swift 4 than delayed until later
releases. Relative to Swift 3, the bar for such changes is significantly
higher:
- The existing syntax/API being changed must be *actively harmful*.
- The new syntax/API must *clearly* be better and not conflict with
existing Swift syntax.
- There must be a *reasonably automatable migration path* for
existing code.
-
*Improvements to existing Standard Library facilities*: Additive changes
that improve existing standard library facilities can be considered. With
standard library additions in particular, proposals that provide
corresponding implementations are preferred. Potential focus areas for
improvement include collections (e.g., new collection algorithms) and
improvements to the ergonomics of Dictionary.
-
*Foundation improvements*: We anticipate proposing some targeted
improvements to Foundation API to continue the goal of making the Cocoa SDK
work seamlessly in Swift. Details on the specific goals will be provided as
we get started on Swift 4 stage 2.
On Sat, Feb 18, 2017 at 11:59 PM, Kevin Nattinger via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’d like to revive an additive proposal that couldn’t make it into Swift
> 3. This proposal has a small improvement to the language compared to other
> big features currently being proposed. It almost feels like a bug fix
> rather than a new feature, but it still needs a full and quick review
> process.
>
> You can read the formatted version here: https://github.com/
> apple/swift-evolution/pull/608
>
> Just MHO, but I consider this syntactic sugar, not a fundamental feature
> that fits the goal of Swift 4 stage 2.
>
>
> Not that I’m necessarily in favor of this change, but my impression was
> that the whole point of stage 1/2 was that anything not allowed in stage 1
> is fair game in stage 2 (if it happens; that doesn’t seem to be likely at
> this point). What exactly is the goal of stage 2 then, should there
> actually be time for it?
>
>
> I’m also pretty opposed to doing it at any time. The rationale of
> “implicit return” in closures is specifically because they are limited to a
> single expression, which makes the semantics “obvious”. This was carefully
> considered.
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
