I understand the review is over, but I’d like to address this point.
It is evident from the review thread that a substantial number of people see an important difference between functions and property getters, even if no one was quite able to put into words the nature of that difference.
To the best of my understanding, it essentially boils down to the review question:
That is obviously a subjective question, and its answers will be subjective as well, but it is nevertheless part of the review template so I don’t think it’s fair to brush off these concerns out of hand.
I’m not sure I can sufficiently explain the reasoning, but I will do my best:
A func declaration creates a subroutine, which can be called from other code. That other code, at the call site, expects a value to be returned (we’re talking non-void functions here). Therefore the function body should contain a return statement to match expectations. If there is no return, then there is an impedance mismatch between the definition and use of the function.
On the other hand, a computed property does not “feel like” a subroutine. Even if it is implemented as a function call under the hood, at the use-site it looks and feels like a property access. Indeed, the mere fact that Swift supports computed properties at all, rather than making people use bona fide functions instead, shows that the designers of the language recognize the importance of this distinction.
When the code block defining a computed property is just a single line—especially when it is on the same line as the property declaration itself—people don’t think of it as a function at all. They see it as describing a value, rather than defining a subroutine.
I know that might sound like splitting hairs, but again, many people in the review thread see the difference as real, and the very existence of computed properties indicates that the creators of Swift understand the distinction as well.
• • •
It is similar with in-line closures. In something like students.map{ $0.name }, the part in curly braces doesn’t *feel* like a function. Yes, it *is* a function, but people don’t think of it that way. They think of it as describing a value.
It would be an impedance mismatch to require return in such a closure, because people don’t think of it as a function. Readers would have to stop and think, “Wait, what is this returning from? Is the enclosing function returning now? No, it can’t be that, let’s see… ah right, the trailing closure is technically a function, so the return is really just local to that closure and doesn’t actually do anything here.”
Along the same lines, with a computed property the currently-required return tends to make people pause and go, “Why is there a return here? We’re not inside a function, this is the body of a struct. Oh… yeah… the computed property getter is technically a function.”
• • •
Essentially, we have a large number of people stating in the review thread that they believe omitting return from a single-expression computed property definition *does* fit the feel and direction of Swift, whereas omitting return from a single-expression func declaration does *not* fit the feel and direction of Swift.
As far as I can tell, this is because func declarations look and feel like functions—which get called as subroutines—so whenever they return a value to the caller they should say that they are doing so with a return statement. Conversely, computed properties look and feel like property accesses, so a return statement seems entirely out of place.
It is a matter of “the feel and direction of Swift”, and we saw many people in the review thread expressing the same opinion on this matter. It is no surprise that these opinions did not include a rigorous logical derivation of their position: they are opinions, answering a subjective question, which specifically asks about the “feel” of the language.
, so I don't want this to sound like I want relitigation. However, I have a small bit of feedback regarding the acceptance of this proposal.