I think the ideal rule is one that can be easily learned by observation of existing code. I don't think this is such a rule. I think the current rule is such a rule, but it seems some people disagree. :-)
The new rule has the disadvantage that it's hard to learn what the actual rule
is, versus the house style, from reading examples; but the advantage that it
doesn't matter what you learn since your code will still work.
Glenn
On Aug 2, 2012, at 10:03 AM, Niko Matsakis wrote:
> There is another option. Right now we have a number of "expressions" that
> can only really be used as statements:
>
> a = b
> a += b
> loop { }
> while cond { }
> return
> ...
>
> These all have unit (or bottom) return type. We could require semicolons
> after these. At least you would not then be able to write:
>
> if cond { return }
>
> but rather
>
> if cond { return; }
>
> and not
>
> fn foo() -> int { return 22 }
>
> but rather
>
> fn foo() -> int { return 22; }
>
>
>
>
> Niko
>
> On 8/2/12 9:47 AM, Patrick Walton wrote:
>> On 08/02/2012 09:15 AM, Gareth Smith wrote:
>>> > Thus this is in practice a backwards-compatible change intended to
>>> eliminate a good deal of toe-stubbing.
>>>
>>> IMHO the source of the toe-stubbing may be that rust has so many
>>> different ways to return a value:
>>
>> I'm not sure. The complaints I've seen (see the mailing list thread, or the
>> bug [1], or various other private/public comments) are specifically about
>> the trailing semicolon being significant.
>>
>> It also doesn't seem possible to fix this in the way you suggest. There are
>> two ways:
>>
>> 1. Require "return", turning Rust back into a statement-oriented language
>> instead of an expression-oriented one. I think it's too late to make such a
>> drastic change. Besides, this is likely to make functional programmers
>> unhappy.
>>
>> 2. Remove "return". This eliminates a huge amount of expressiveness. Many
>> functional languages don't have "return", but they get around it with monads
>> or exceptions, neither of which we have good support for.
>>
>> Also, Perl is an example of a curly-brace language in which both syntaxes
>> work. JS is related -- it has the notion of a "completion value" for blocks,
>> although you don't implicitly return the completion value.
>>
>> (As an aside, "return" not working inside lambda blocks is an issue, but
>> that's basically because making it work would either introduce an
>> unacceptable performance penalty, equivalent to C++ try/catch, or be
>> inconsistent with the way it works in "for" blocks.)
>>
>> Patrick
>>
>> [1]: https://github.com/mozilla/rust/issues/1712
>>
>> _______________________________________________
>> 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
>
>
> !DSPAM:501aadaa175111014834540!
>
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
