DevAndArtist:
Excuse me? Can I ask why my proposal of the exact same thing was pushed back so hard especially by @Chris_Lattner3 back then? I appreciate all the work that author has done on this proposal but he missed the historical research on why this was not pushed forward so far.
By this comment this feature was simply put onto the bookshelf for many many years until Swift evolved so much that there is not much to add except convenient sugar:
[Proposal] [Stage–2] return consistency for single-expressions
Beyond that, though syntactic sugar is always motivated by strong rationale and use-cases, in my opinion, it is the most dangerous kind of additive feature to consider at this point of Swift’s evolution. While these features are useful, they also clearly add complexity to the language, and it is difficult to gauge whether the problem being addressed will even exist in Swift as the other bigger features come in (for example, a macro system). These features can also make future language evolution more problematic because they consume syntactic real estate in the language.
If you’re into analogies, I see features like the generics improvements, ownership model, concurrency model, macro system, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, syntactic sugar proposals are “mortar” that fills in the cracks between the bricks. If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places. That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.
-Chris
FWIW, I still feel exactly the same way about this, and I find that the "just omit the return" proposal to be super problematic from a clarity perspective.
The func f() -> Int = 42 variant is a significant improve on that clarity issue, but I still don't think it is "worth it" to add complexity to the language for this.
-Chris
9 Likes