On 6/7/12 2:20 PM, Gareth Smith wrote:
I think that allowing an early exit with a break/continue from lambdas
that use this special form is confusing, because breaking may or
may-not actually resume the code that follows the do-call. The lambda
might be put into a data structure for later
On 6/7/12 1:41 PM, Gareth Smith wrote:
Hi Rust-Dev,
I have recently (using the latest rust from github) encountered some new
warnings about implicitly copying a non-implicitly-copyable value. I
believe this is due to the fix for
https://github.com/mozilla/rust/issues/2450.
This warning seems
On Thu, Jun 7, 2012 at 2:27 PM, Patrick Walton pwal...@mozilla.com wrote:
On 6/7/12 2:20 PM, Gareth Smith wrote:
If you allow all block lambdas to have early returns with ret, then this:
fn f() {
for int::range(1, 10) |i| {
ret i;
}
}
Has a very different
On 6/7/12 3:14 PM, Erick Tryzelaar wrote:
(As an aside, it sure would be nice if the fn@ closures inferred their types...)
I wrote this code. I only didn't push it because I couldn't decide what
to do with unspecified return types. i.e., should `fn@() { 3 }` have an
inferred return type of
On Thu, Jun 7, 2012 at 3:52 PM, Graydon Hoare gray...@mozilla.com wrote:
The return type when used as an expression, maybe. When declared as an item,
I'd like to keep the signatures mandatory. That was a very intentional
choice. Both for keeping inference function-at-a-time (fewer ways to go
Dear Rusties,
I am currently writing in C++ code that involves long strings of `if
... else if ... else if ... else if ...` and it dawns to me that we can
certainly sightly tweak the syntax of Rust to make such code much nicer.
Consider the following extract:
if (f()) {
// ...
}
On 6/7/12 10:27 PM, David Rajchenbach-Teller wrote:
I believe that this snippet has a more immediately visible structure
than the original and is easier to read, while the syntax tweak is
trivial to compile.
What do you think?
How about a Scheme-like cond macro?
Patrick
