[rust-dev] RFC: Ignore trailing semicolons

Glenn Willen gwillen at nerdnet.org
Wed Aug 1 19:03:01 PDT 2012


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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
> 
> 
> !DSPAM:5019d823101041336712104!
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120801/43f5796e/attachment.sig>


More information about the Rust-dev mailing list