> On Feb 17, 2017, at 8:41 AM, Vladimir.S via swift-evolution > <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
