Good post! I would just add that for me, `@autoclosure` is best reserved for situations where you have a parameter value that a) could be expensive and b) may never need to be executed.
The nil-coalescing example is a good one, in that if the optional value you're coalescing is not nil, the remainder of the expression never need to execute.
Another classic example is `assert`. For example:
```
assert(someValue == someOtherValue, "Expected \(someOtherValue) but got \(someValue).")
```
Both the condition being tested and the message have a processing cost. If we're not running in debug mode, assertions always pass, so processing them would be less efficient. And the message will only be output when the assertion fails.
So, this is where autoclosure is useful - it makes it simple to wrap up code that may not need to execute.
Good post! I would just add that for me, `@autoclosure` is best reserved for situations where you have a parameter value that a) could be expensive and b) may never need to be executed.
The nil-coalescing example is a good one, in that if the optional value you're coalescing is not nil, the remainder of the expression never need to execute.
Another classic example is `assert`. For example:
```
assert(someValue == someOtherValue, "Expected \(someOtherValue) but got \(someValue).")
```
Both the condition being tested and the message have a processing cost. If we're not running in debug mode, assertions always pass, so processing them would be less efficient. And the message will only be output when the assertion fails.
So, this is where autoclosure is useful - it makes it simple to wrap up code that may not need to execute.