[rust-dev] RFC: Ignore trailing semicolons

Niko Matsakis niko at alum.mit.edu
Thu Aug 2 09:59:16 PDT 2012


My "official position" is unopposed.  I personally like the rule about 
omitting the trailing semicolon, it makes it syntactically clearer when 
a value is being returned, but I understand some people have also 
complained about it.  Your change seems to be a relatively simple way to 
make the presence or absence of a trailing semicolon irrelevant.

One thing I am wondering about.  The other unpopular semicolon rule (for 
which I am responsible) is the rule that a semicolon is required for a 
`do` or `for` with a non-unit result.  This rule never bits me but I 
understand it occasionally bites users of the task API.  Did you undo 
this rule?  (And, if so, do we plan to replace with a 
whitespace-sensitive warning?)


Niko

On 8/1/12 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



More information about the Rust-dev mailing list