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

[Matthew Johnson]

+1.  I have always thought this sugar should be consistent throughout the language.

> On Feb 17, 2017, at 2: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 <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 <x-msg://423/#rationale>
> 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 <applewebdata://86ADDB79-FDC5-4935-A422-C0817D7EEFA1> * [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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/c2deaeec/attachment.html>