> 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 <mailto: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 >> <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
