[swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions

[Xiaodi Wu]

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 at swift.org> wrote:

>
> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> 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/20170219/208eb644/attachment.html>