On 8/2/12 7:05 PM, Patrick Walton wrote:
On 8/2/12 7:04 PM, Kevin Cantu wrote:
Why wouldn't that fit in? I'm missing something here.
Because ordinarily a semicolon means that the value is returned, but in
this case it wouldn't.
Err, ordinarily a semicolon means that the value is *ignored*.
On 8/2/12 7:04 PM, Kevin Cantu wrote:
Why wouldn't that fit in? I'm missing something here.
Because ordinarily a semicolon means that the value is returned, but in
this case it wouldn't.
A clearer example would probably be:
let x = match foo {
'a' => 1;
'b' => 2;
Why wouldn't that fit in? I'm missing something here.
On Thu, Aug 2, 2012 at 6:20 PM, Patrick Walton wrote:
> There is another issue I forgot to mention, which is the match clause
> separator.
>
> Currently, "match" (formerly "alt") clauses must either be separated by a
> closing brace '}' or
There is another issue I forgot to mention, which is the match clause
separator.
Currently, "match" (formerly "alt") clauses must either be separated by
a closing brace '}' or a comma ','. We can't use '|' like ML because of
bitwise-or.
So we have:
match foo {
'a' => 1,
I've hesitated to comment so far because I didn't understand what people were
complaining about, but I like the current system better than any of these
proposals. Coming from mostly C style languages, I didn't have any problem
understanding it or using it.
Ted
___
On Thu, Aug 2, 2012 at 12:51 PM, Emmanuel Surleau
wrote:
> Hi,
>
> I'm new to rust, and I'm struggling to find an elegant way to work with
> default
> parameters.
>
> I'm trying to implement in rust the equivalent of the following Python line:
>
> def flag(self, name, desc, short_name=None, max_c
Hi,
I'm new to rust, and I'm struggling to find an elegant way to work with default
parameters.
I'm trying to implement in rust the equivalent of the following Python line:
def flag(self, name, desc, short_name=None, max_count=1, banner=None):
...
The idea is to offer a "simple" API (with o
On 8/2/12 9:59 AM, Niko Matsakis wrote:
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
I personally think the current/old rule is good; at least to me, it is
completely clear what is going on - semicolon means terminate statement, and
the last (unterminated) statement is returned, unless a short-circuit return
exists. Mixing functional/imperative code is tricky, but I think this r
On 8/2/12 9:52 AM, Glenn Willen wrote:
But now that I see that the new syntax is effectively the same one
Perl uses, I'm not super worried about it, as long as we adopt the same
house style that Perl programmers use: The semicolon is _always_
present, except in cases where it's too ugly (which i
On 8/2/12 10:07 AM, Erick Tryzelaar wrote:
fn h() -> int {
f(); // result ignored
g(); // result returned
}
It's true, I feel like the current scheme does a better job of
highlighting when a seemingly unused value is significant.
I don't know, I always liked the current rule regarding
On Thu, Aug 2, 2012 at 10:03 AM, Niko Matsakis wrote:
>
> 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() -> in
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
I'm coming from functional-programming-land, so I'm quite fond of our
current scheme. These seems a bit surprising to me:
fn f() -> int { 3 }
fn g() -> int { 4 }
fn h() -> int {
f(); // result ignored
g(); // result returned
}
I'm probably pretty biased, but I don't think this is a complic
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 n
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 pres
On Aug 2, 2012, at 9:13 AM, Patrick Walton wrote:
> If the semicolon were mandatory at the end of blocks, you'd have to write:
>
>let x = if cond { 3; } else { 5; }
>
> Which would be a non-starter, IMHO.
So looking at this example made me realize that I do know one language that
uses an
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 (s
On Thu Aug 2 12:13:09 2012, Patrick Walton wrote:
On 08/02/2012 09:10 AM, Donovan Preston wrote:
I would be more in favor of this proposal if the semicolon was not
optional. Having the ability to have code that is identical except for a
semicolon just doesn't feel right to me.
If the semicolo
> 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:
fn f() -> int { 42 }
or
fn f() -> int { ret 42 }
or
fn f() -> int { ret 42; }
And re
On 08/02/2012 09:10 AM, Donovan Preston wrote:
I would be more in favor of this proposal if the semicolon was not
optional. Having the ability to have code that is identical except for a
semicolon just doesn't feel right to me.
If the semicolon were mandatory at the end of blocks, you'd have to
I would be more in favor of this proposal if the semicolon was not
optional. Having the ability to have code that is identical except for
a semicolon just doesn't feel right to me.
On Thu Aug 2 11:58:03 2012, Patrick Walton wrote:
On 08/02/2012 08:43 AM, Glenn Willen wrote:
But blocks are no
On 08/02/2012 08:43 AM, Glenn Willen wrote:
But blocks are now allowed to discard their values, where previously
this was forbidden? That is, before, it was an error to say:
fn foo() {
5
}
But now it will be allowed? (I notice that in your first email you
said that return values could alr
On 08/02/2012 08:31 AM, Benjamin Striegel wrote:
Ah, so semicolons are absent by default? That seems like the right
decision; making semicolons optional and yet canonicalizing their
universal use almost certainly leads to contention down the road (cf
Javascript).
I think there's a bit of confus
On Aug 1, 2012, at 8:47 PM, Patrick Walton wrote:
>
> Actually, the only parser change was to throw away semicolons before the end
> of the block.
>
> To be more concrete, the rules are:
>
> 1. The last expression is the value of the block, regardless of whether
> there's a semicolon after it.
> Right now the official style is what is currently done; semicolons are
only used when ignoring a value.
Ah, so semicolons are absent by default? That seems like the right
decision; making semicolons optional and yet canonicalizing their universal
use almost certainly leads to contention down the
On 08/02/2012 07:22 AM, Benjamin Striegel wrote:
Questions:
1) Are there any complications with spanning multiple lines?
No. This change doesn't make Rust whitespace sensitive in any way.
2) What is the official style?
Right now the official style is what is currently done; semicolons are
Questions:
1) Are there any complications with spanning multiple lines?
```
let foo = bar + baz + "some long string literal that takes us out to 80
chars"
+ qux + "and continued on this line"
do something_else { ...
```
2) What is the official style?
On Wed, Aug 1, 2012 at 11:47 PM, Pa
28 matches
Mail list logo
