This is untrue – the proposal to omit returns in single-expression functions made no such call outs.
Omitting ceremony is about making both reading and writing code easier. Since Swift 1.0, long before SwiftUI or other APIs that you incorrectly claim were the only motivation for that proposal, you have been able to omit returns from closures. Why? Because doing so makes them easier both to read and to write. numbers.map { $0*2 }
is more readable than numbers.map { return $0*2 }
. Requiring a return
is ceremony, and reduction of ceremony is better for both writing and reading code.
SE-0255 extended that logic to functions and computed properties. var startIndex: Index { _base.startIndex }
is also more readable without the return
, at least I think so.
This proposal takes that position further. The argument is that this code is more readable, as well as writable, than the equivalent where the return
ceremony must be duplicated on each branch:
private func balance() -> Self {
switch self {
case let .node(.Black, .node(.Red, .node(.R, a, x, b), y, c), z, d):
.node(.Red, .node(.Black,a,x,b),y,.node(.Black,c,z,d))
case let .node(.Black, .node(.Red, a, x, .node(.Red, b, y, c)), z, d):
.node(.Red, .node(.Black,a,x,b),y,.node(.Black,c,z,d))
case let .node(.Black, a, x, .node(.Red, .node(.Red, b, y, c), z, d)):
.node(.Red, .node(.Black,a,x,b),y,.node(.Black,c,z,d))
case let .node(.Black, a, x, .node(.Red, b, y, .node(.Red, c, z, d))):
.node(.Red, .node(.Black,a,x,b),y,.node(.Black,c,z,d))
default:
self
}
}
Is this game changing? No. Is this a quality of life improvement that has strong demand from the community, and which is the baseline expectation for users of other modern languages? Absolutely.
Now this is of course a matter of taste and opinion. Some think the return
improves readability, and would prefer to see it even on closures. Some might also think that semicolons at the end of lines, parenthesis around if
conditions, and explicit types for variable declarations are also more clear. But those are not the aesthetics of Swift. Disagreeing is fine – but re-litigating settled disagreements, and imputing motivations for proposals as driven by marketing or specific frameworks not by a desire to improve the language is not fine.