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
