Expression syntax and semicolon

[xjia1]

Hi, I'm a Rust language newbie so what I mention below may be non-sense. :-)

I think it is not that wise to make use of semicolon (;) as the separator between statements along with the expression syntax provided in the language, because it will potentially lead to many typo-caused bugs. For example, for the following snippet from the Rust language tutorial:

let x = if the_stars_align() { 4 }
        else if something_else() { 3 }
        else { 0 };

If the expressions inside the braces are function calls, it would be harder to decide:

let x = if the_stars_align() { my_pretty_print_function(123) }
        else if something_else() { your_pretty_print_function(456) }
        else { our_error_print_function(789) };

and

let x = if the_stars_align() { my_pretty_print_function(123); }
        else if something_else() { your_pretty_print_function(456); }
        else { our_error_print_function(789); };

[catamorphism]

I'm not sure I understand the question. If x is used in a context that expects a type other than nil, the second version of the code would be a type error, because all of the if branches have type nil (the trailing semicolon says "do this and throw away the result", so the blocks all have type nil).

Maybe I'm missing something, though?

[lht]

@catamorphism It is actually not an error if x is assigned to nil type like the last example above. Or, are we going to change this?

[catamorphism]

@lht Yes, it's not an error, but it would be an error to use x (except by, say, passing it to a function that had an argument of type nil, but you probably would never write such a function). I'm still not exactly sure what the situation is that you're worried about that would be confusing -- can you explain further, maybe with a code example for the part of the code that uses x?

[xjia1]

• Would it be complicated if x is passed across abstraction boundaries?
• Would it be much harder to locate where the exact problem source is (in this case the semicolons inside the braces of the let x statement) if x is later used in many other lets and expressions inside an abstraction boundary?
• What if the previous two cases mixing together?

I think semicolons in the expression syntax should be forbidden (maybe in the phase of semantics analysis) since let x = nil doesn't seem useful from my perspective. And it may confuse some not-that-experienced programmers. Such kind of easy typos may also fail an integrated compilation and test quickly which I think is not that good since it will possibly make everyone jittery.

[lht]

See also #1195, which suggests adding better compiler warning or error messages.

[nikomatsakis]

I don't see this as a problem. We are certainly not going to prohibit semicolons in blocks. They are very useful. I could see a warning if some branches of an if or alt have no tail expression while others do, though I am inclined against it as any real problem will be caught by type checker. I am going to close this issue but feel free to add to #1195 concerning a warning if you feel that would be appropriate.

Sent via Hubroid