[swift-evolution] [Proposal] =?utf-8?Q?=5BStage=E2=80=932=5D_?=`return` consistency for single-expressions

[Adrian Zubarev]

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) 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  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/e7c9fd04/attachment.html>