This works surprisingly well in Rust. From just the description of the feature you could easily assume it’d cause endless bugs and confusion… but it just doesn’t. The type system and the rest of the syntax are robust enough to make it work.
However, Rust’s syntax requires semicolons after statements (in most cases that don’t return a value). I don’t know if Swift’s optional semicolons wouldn’t make it just a bit too implicit.
Semicolonlessness works great in Swift today; I’ve basically never thought about explicitly delimiting statements in this language.
One odd case of new ground might be: Your final expression begins with a bare dot operator, and you intend for it to return a static member of the known return type, but it’s parsed as a method call on the prior line.
In Rust, semicolons tell the compiler that you just call these functions, and don’t return the value. Without semicolons, it would be a type error, because then and else branches return a different type.
Ah sorry, that’s a different problem than I had in mind. Here’s a tour:
Swift requires no semicolons unless you want two statements on a line, and statements may still span multiple lines. I assume the grammar has that much figured out because in practice I don’t struggle with clarifying what’s a wrapped statement and what’s two statements.
In function bodies, if there’s only one expression and the return type is not Void / (), it’s treated as a return statement. Otherwise it’s just an expression.
On the calling end, a function call expression is an error if it produces a result that isn’t used somehow. One way to use it is to assign to _ to silence the error while leaving intent clear to the reader.
A single expression for a function body can be an if-else or a switch, but I believe to qualify as an expression rather than a statement, the cases of those need to also have just a single expression. This proposal would change that. It’s just that, since semicolons are unwanted, the distinction between a final expression and a final statement would need to be established some other way, and I wonder if in this case it can be solved neatly.
Here’s a comment that evaluates Rust’s treatment as if it were a Swift feature.
this cannot be done because an API is structured to require you first create a value, then mutate part of it
Another interesting option I’ve seen is Ada’s extended return. “We return this variable after these steps.”
return Result : Integer := 10 do -- can specify an initial value
-- steps doing calculations
if Result > 50 then return; end if; -- returning in middle returns the result.
Result := 40;
-- value is returned automatically at the end
end return;
Swift getting this would make me seriously consider using it instead of Rust for most things where I don’t care about performance as much, because the confusion about where things are statements and where they are expressions is one of my biggest annoyances with it coming from Rust. But then, I am not an active user myself, so I don’t think my opinion should count over those of Swift users.
I encourage you to try it out. Swift has been designed with an eye on clarity for the reader. For example, the try keyword is a no-op but is required before any expression that can throw, just so a reader always knows the few places that execution may jump out.
There’s a lot of guidance about article titles on the Submit page. As a result my habit is to use the original page title, drop a site prefix if present, clean up any clickbait phrasing, and let the tags give categorical context.
This works surprisingly well in Rust. From just the description of the feature you could easily assume it’d cause endless bugs and confusion… but it just doesn’t. The type system and the rest of the syntax are robust enough to make it work.
However, Rust’s syntax requires semicolons after statements (in most cases that don’t return a value). I don’t know if Swift’s optional semicolons wouldn’t make it just a bit too implicit.
Semicolonlessness works great in Swift today; I’ve basically never thought about explicitly delimiting statements in this language.
One odd case of new ground might be: Your final expression begins with a bare dot operator, and you intend for it to return a static member of the known return type, but it’s parsed as a method call on the prior line.
In Rust, semicolons tell the compiler that you just call these functions, and don’t return the value. Without semicolons, it would be a type error, because then and else branches return a different type.
How does Swift disambiguate this?
Ah sorry, that’s a different problem than I had in mind. Here’s a tour:
Swift requires no semicolons unless you want two statements on a line, and statements may still span multiple lines. I assume the grammar has that much figured out because in practice I don’t struggle with clarifying what’s a wrapped statement and what’s two statements.
In function bodies, if there’s only one expression and the return type is not Void / (), it’s treated as a return statement. Otherwise it’s just an expression.
On the calling end, a function call expression is an error if it produces a result that isn’t used somehow. One way to use it is to assign to _ to silence the error while leaving intent clear to the reader.
A single expression for a function body can be an if-else or a switch, but I believe to qualify as an expression rather than a statement, the cases of those need to also have just a single expression. This proposal would change that. It’s just that, since semicolons are unwanted, the distinction between a final expression and a final statement would need to be established some other way, and I wonder if in this case it can be solved neatly.
Here’s a comment that evaluates Rust’s treatment as if it were a Swift feature.
I find it a bit weird in Kotlin with blocks and lambdas. Rust feels more intuitive.
Another interesting option I’ve seen is Ada’s extended return. “We return this variable after these steps.”
Swift getting this would make me seriously consider using it instead of Rust for most things where I don’t care about performance as much, because the confusion about where things are statements and where they are expressions is one of my biggest annoyances with it coming from Rust. But then, I am not an active user myself, so I don’t think my opinion should count over those of Swift users.
I encourage you to try it out. Swift has been designed with an eye on clarity for the reader. For example, the try keyword is a no-op but is required before any expression that can throw, just so a reader always knows the few places that execution may jump out.
Why not to prefix title with Swift? 😑
Isn’t the tag enough?
When you scroll RSS feed you don’t see any tags
Noted. Maybe a patch to include tags somehow in the RSS titles would be appreciated.
I’d think the URL is also a dead giveaway being at swift.org.
RSS has a
<category>element; articles can be tagged with their categories in the feed.So it does! That’s even better.
There’s a lot of guidance about article titles on the Submit page. As a result my habit is to use the original page title, drop a site prefix if present, clean up any clickbait phrasing, and let the tags give categorical context.