I agree with Glenn. I personally did not have an issue while trying to pick up Rust to figure out the implicit return with the lack of the semi-colon. In fact, I was able to pick up this pattern just by browsing some Rust code and not looking at the manual or tutorial pages. :)
I also think that it is easier to parse visually the way it is now. -- Ziad On Wed, Aug 1, 2012 at 7:03 PM, Glenn Willen <[email protected]> wrote: > I for one liked the clear and unambiguous rule: semicolon discards value, > no-semicolon returns value. > > The idea of allowing uniform semicolon use is appealing, but it does seem > to add complexity and mysteriousness. > > FWIW, since I'm not exactly a major player in the Rustiverse currently. :-) > > gwillen > > On Aug 1, 2012, at 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 > > > > > > !DSPAM:5019d823101041336712104! > > > > > _______________________________________________ > 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
