Background: I have been teaching programing for 13 years now. It is possible that you have been doing the same, and you just don't see the issues that I have. I accept that we can have different experiences when it comes to 'newcomers' and 'new programmers'
That is simply not true. The existing rule comes out of an affordance given to @autoclosure that felt right because it simplified single line entires that were really easy to debug, albeit sometimes confusing especially when all you were writing was <. (This is NOT easy for newcomers btw)
Yet, these contexts are so very simple, you would never have pages of code to scroll through to find the return value. You would have exactly ONE line to deal with that that line alone could be the only culprit. This affordance was allowed because it sort of matched what was already happening inside parameters.
It ways always a ay of making closures within parameters kinda behave like the expressions.
You would, for example, never have to say
doThisThing(x: return 1, y: return 2, z: return 3).
Again, these would always be single lines anyway.
So then it was asked that we extend this to all single line closure (I believe).
I kinda objected to this, I think, because it served a sort of philosophical niche in parameters that didn't NEED exist outside of that. I think if Swift was made today, I would have never invented autoclosures as it hides too much of what is actually happening (this is unsafe in my opinion).
But it wasn't a big deal. It was ONE line. There really could be no major confusion about what was being returned.
Single line, allowed. Multi lined, not allowed. Very simple to understand, very simple to keep straight for newcomers.
But not always, because newcomers and new learners of programming often confuse that a body of a function and closure are different than a body in if-statement (this is about to get mudded even more). Why for example, in the body of an if expression can I not simply state the return value and it would early exit? It LOOKS kinda like a closure -- but it's not.
What if it were allowed in if-expressions? Do now all of my @discardableResults become a potential return value?!
That is absolutely dangerous.
What if it were allowed in multi-lined closures/functions and in the course of development I comment out my return statement and now a unsuspecting discardableResult becomes the return value? In the past, the compiler would warn me that I didn't write 'return '. Giving me clear notice that I need to pay attention to what comes out of this function.
What happens if I continue to develop a function, not notice that I had already returned, and I continue to type code.
I have been teaching Swift for 13 years now to young adults. I am honest when I say this, Swift is starting to become a programming language for experts. This is another step in the wrong direction of creating a language that is SAFE, explicit and easy to read.
When I teach programming now, there are things I have found are better to NEVER mention until much later in the year. 1) implicit types 2) trailing closures (all my example code puts the closure inside the (). 3) eliding return in single line closures (with some exception). They very frequently leave the students confused. It is always very difficult to explain why result builders do the funny things they do with if statements. But each of those are far less dangerous that was is being proposed here. This actually causes the program to yield values in functions that can be passed down through a call chain. In functions that are hundreds of lines long, this is unacceptable.
So please, I beg people to listen to the naysayers who are advocating for something to really be thought about in practice. Not with the brains that we have. We read code all day. We see these discussions and participate fully in the debate of how a new idea will be implemented. Even when we dislike it we will easily understand how it works.
This pitch is a decoration (not a feature) that would only exist because it feels a particular way. Not because it is needed. Not because it is safer. Not because it makes for a measurably better language that enhances the final result (the built program).
For those who feel that this pitch creates consistency despite at the expense of clarity, okay, than I prefer to be inconsistent. Some inconsistencies deserve to remain.
This pitch creates MORE confusion and more rules not less especially when we considered all the other side effects and exceptions that may need to be carved out. And the very fact this is decoration is not needed. We need features for the language that encourage safety not decorations for the language that encourage being less explicit.