My "official position" is unopposed. I personally like the rule about
omitting the trailing semicolon, it makes it syntactically clearer when
a value is being returned, but I understand some people have also
complained about it. Your change seems to be a relatively simple way to
make the presence or absence of a trailing semicolon irrelevant.
One thing I am wondering about. The other unpopular semicolon rule (for
which I am responsible) is the rule that a semicolon is required for a
`do` or `for` with a non-unit result. This rule never bits me but I
understand it occasionally bites users of the task API. Did you undo
this rule? (And, if so, do we plan to replace with a
whitespace-sensitive warning?)
Niko
On 8/1/12 6:53 PM, Patrick Walton wrote:
Hi everyone,
I have a patch that allows trailing semicolons in most cases in Rust
code. This means that code like this will compile:
fn f(x: int) -> int {
x + 3;
}
At the moment, this does not compile. You must write:
fn f(x: int) -> int {
x + 3
}
For the most part, it does not alter the current rules as to whether
return values can be ignored. Return values can continue to be ignored
in almost all contexts; I didn't have to change any code in the
compiler or standard libraries. Thus this is in practice a
backwards-compatible change intended to eliminate a good deal of
toe-stubbing.
There is one subtle source of backwards-incompatibility though: You
may not drop the return value in sugared lambda expressions if you
assign them to a variable (i.e. if the type isn't immediately known).
Thus this does not do what it did before:
// This return value is intended to be ignored.
fn f() -> int {
error!("Hi!");
3
}
fn main() {
let g = || { f(); };
error!("%?", g()); // prints 3, not ()
}
I personally feel that this particular gotcha is a small price to pay
for eliminating a frequent source of newcomer frustration, but it is
worth pointing out. Note that this does not apply for downward block
closures; if you're passing a lambda to a function, the return value
of the lambda can be safely ignored as before if the lambda is
intended to return unit.
Another downside is that some complexity is added to typechecking; the
typechecker is now aware of statement positions (which are expected to
return unit) and expression positions (which aren't). Note that Scala
seems to have already implemented a rule similar to this, so it isn't
without precedent; it also affects only how HM inference is invoked,
not the nature of unification itself.
I'd like to get feedback as to whether this is a good idea. Comments
welcome!
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
