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

[Matthew Johnson]

> 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