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!
>
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
