Avoid curly brackets on single line bodies and computed properties

Evolution Discussion
21

that sounds like precondition to me.

22

Let's not get sidetracked about guard. It isn't return "every single time". Sometimes it's break or continue or fallthrough or throw.

This has been discussed other places, such as:

Inferred return for guard statement
An implicit return for guard
Proposal: Add implicit/default else-behaviour for the guard statement

No need to repeat all that here, right?

4 Likes
23

I'm against this because this will introduce difference in defining various code blocks. For example, Kotlin allows to drop brackets in single-statement if bodies, which wouldn't be possible in Swift because of absence of braces in if conditions. If we'll allow dropping brackets in function and property bodies then Swift will lose it's current uniformity which states that almost any new scope (except case body in switch statement) needs to be wrapped in curly brackets

4 Likes
24

The brackets { and } define a function, a closure or a block of code.
With return no longer required whenin single line function, the suggested things can pretty well be achieved as follows.. of course with using { and }:

public var elements: [Bool] = [x, y]

public func makeIterator() -> IndexingIterator<Array<Bool>>  { elements.makeIterator() }

public var debugDescription =  String(describing: type(of: self)) + "(\(x), \(y))" 

public func hash(into hasher: inout Hasher) { hasher.combine(SGLMath.hash(x.hashValue, y.hashValue)) }

public static func ==(v1: Vector2b, v2: Vector2b) -> Bool { v1.x == v2.x && v1.y == v2.y }

And this is all Swifty.
The typical guard statement in Swift is as follows (say this is initial code):

    guard let password = passwordTextField.text,
          password.count >= 6  else {
            return false
    }

This is how it will look transform with this suggested improvement. Please feel free to correct if I am wrong here.

    guard let password = passwordTextField.text,
          password.count >= 6  else 
          return false

This is a bit confusing. And later on when additional things needs to be done in guard else like below:

    guard let password = passwordTextField.text,
          password.count >= 6  else {
            showAlert()
            return false
    }

And it could incidentally, by programming error, become as follows and return false might go out of guard-else statement:

    guard let password = passwordTextField.text,
          password.count >= 6  else 
          showAlert()
          return false

One of the aspects when Swift was introduced was, Swift avoids common coding errors and { and } even for single line if statement. This was highlighted. I think we need to stick with this premise/aspect.

1 Like
25

Ok, putting my considerate hat on, I think itā€™s been documented a number of good reasons why this is probably not a good direction to go in due to inconsistency with the = operatorā€™s existing use.

Taking my considerate hat off, what on earth is with all the proposals every 3 seconds to remove every conceivable keyword, piece of syntax, and practically everything from Swift? Everyone could come in and say ā€œI donā€™t like this bit, letā€™s remove itā€ about literally any part of the language. Where does it end? :face_with_raised_eyebrow::man_shrugging:

8 Likes
26

This would create a stored property, not a computed one. In fact, it would do that in Kotlin, too. If we ported the Kotlin feature to Swift, you'd have to write:

Which hurts my eyes as a Swift developer, and also demonstrates that using = to define both stored and computed properties is perhaps a little too subtle.

18 Likes