> Thus this is in practice a backwards-compatible change intended to
eliminate a good deal of toe-stubbing.
IMHO the source of the toe-stubbing may be that rust has so many different
ways to return a value:
fn f() -> int { 42 }
or
fn f() -> int { ret 42 }
or
fn f() -> int { ret 42; }
And ret cant be used inside lambdas. Except in do/for blocks.
This proposal would add another variant:
fn f() -> int { 42; }
Most curly brace languages have just one way to return a value:
int f() { return 42; }
I would rather that I did not have to make the choice about which syntax to
use. It doesn't seem like a meaningful choice.
Gareth
On 2 August 2012 02:53, Patrick Walton <[email protected]> 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<https://mail.mozilla.org/listinfo/rust-dev>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
