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

[Vladimir.S]

OK, just wanted to confirm that you are not suggesting to allow this in 
'guard'.

On 17.02.2017 18:57, Adrian Zubarev via swift-evolution wrote:
> Exactly, couldn’t say that any better. |guard| was part of this proposal in
> the first draft but was dropped due the same reasons Matthew just described.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 17. Februar 2017 um 15:46:33, Matthew Johnson (matthew at anandabits.com
> <mailto:matthew at anandabits.com>) schrieb:
>
>>
>> > On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>> >
>> > I think I like this, but what about guard?
>> >
>> > func f(x: Int) -> Int {
>> > 	guard x > 0 else { return 0 }
>> > ...
>> > }
>> >
>> > vs
>> >
>> > func f(x: Int) -> Int {
>> > 	guard x > 0 else { 0 }
>> > …
>> > }
>>
>> Any time you have a guard statement you no longer have a single
>> expression. There is at least one expression in the guard clause itself,
>> at least one in the else block, and at least one following the guard
>> statement.
>>
>> >
>> > ?
>> >
>> > On 17.02.2017 11:20, Adrian Zubarev via swift-evolution 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
>> >>
>> >>
>> >>  |return| consistency for single-expressions
>> >>
>> >>  * Proposal: SE-NNNN
>> >>    <https://github.com/apple/swift-evolution/blob/master/proposals/nnnn-single-expression-optional-return.md>
>> >>  * Author: Adrian Zubarev <https://github.com/DevAndArtist>
>> >>  * Status: *Awaiting review*
>> >>  * Review manager: TBD
>> >>
>> >>
>> >>    Introduction
>> >>
>> >> Any single-expression closure can omit the |return| statement. This
>> >> proposal aims to make this feature more consistent in some other corners of
>> >> the language.
>> >>
>> >> Original swift-evolution thread: * [Pitch] [Stage–2] |return| consistency
>> >> for single-expressions * [Pitch] (Bofore Swift 3) Make |return| optional in
>> >> computed properties for a single case
>> >> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019260.html>
>> >>
>> >>
>> >>    Motivation
>> >>
>> >> Closures can omit the |return| and have an inferred return type:
>> >>
>> >> |let _ = { 42 } // Type: () -> Int let _ = [1,2,3].map { $0 * 5 } // T == Int |
>> >>
>> >> There are also value returning code blocks in the language that feel the
>> >> same but are inconsistent to the mentioned feature:
>> >>
>> >> |// Read-write computed property: var integer: Int { get { return 2016 } set
>> >> { /* do some work */ } } // Read-only computed property: var string: String
>> >> { return "hello swift" } // Function: func pi() -> Double { return 3.141 }
>> >> // Read-Write subscript: subscript(index: Int) -> Int { get { return index
>> >> % 2 } set { /* do some work */ } } // Read-only subscript: subscript(index:
>> >> Int) -> Int { return index * 2 } |
>> >>
>> >>
>> >>    Proposed solution
>> >>
>> >> Make |return| optional for the following top level code blocks that only
>> >> contain a single expression:
>> >>
>> >>  * /variable-declaration/
>> >>  * /getter-setter-block/
>> >>  * /getter-clause/
>> >>  * /function-body/
>> >>  * /subscript-declaration/
>> >>
>> >> That will allow us to rewrite the above example to:
>> >>
>> >> |// Read-Write computed property: var integer: Int { get { 2016 } ... } //
>> >> Read-only computed property: var string: String { "hello swift" } //
>> >> Function: func pi() -> Double { 3.141 } // Read-Write subscript:
>> >> subscript(index: Int) -> Int { get { index % 2 } ... } // Read-only
>> >> subscript: subscript(index: Int) -> Int { index * 2 } |
>> >>
>> >> *Possible real world example:*
>> >>
>> >> |// Today public struct Character { public let source: Module.Source private
>> >> let _pointer: UnsafePointer<Swift.Character> public var value:
>> >> Swift.Character { return self._pointer.pointee } ... } // Rewritten: public
>> >> struct Character { ... public var value: Swift.Character {
>> >> self._pointer.pointee } ... } |
>> >>
>> >>
>> >>    Impact on existing code
>> >>
>> >> None, this change will only relax some existing rules.
>> >>
>> >>
>> >>    Alternatives considered
>> >>
>> >> Leave this as is and live with such inconsistency.
>> >>
>> >>
>> >>
>> >> --
>> >> Adrian Zubarev
>> >> Sent with Airmail
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>