Hi,
Also, I believe it is still possible to write:
some_func(..., fn&(x:T) -> R {
if foo { ret; }
..
})
I plan to make the parameter and return types for fn() expressions
inferable as well, which would remove the last annoyance barrier between
"fn&" and "{||".
Niko
On 3/27/12 4:04 AM, Grahame Bowland wrote:
Hi Marijn
Thanks, that all makes sense.
Apart from "complicated" blocks, the other case I've got is
some_iter_func(..) {
if (some_condition) { ret; } // meaning 'cont'
...
}
Where my block is returning (). It sounds like that case will be
handled nicely when 'cont' starts behaving as if you were in a loop,
so that's great.
Cheers
Grahame
On 27 March 2012 18:52, Marijn Haverbeke <[email protected]
<mailto:[email protected]>> wrote:
See issue [1] for some discussion. The reason was that A) people are
bound to expect ret to return from the outer function, which we don't
support in most cases, and B) I am in the process of adding a case
(for loops on top of blocks) where we *do* support returning out of
the outer function from a block, and treating ret differently in
different kinds of blocks seems like a bad idea.
When going over the existing code that was using ret in blocks, I did
find two cases that had to be transformed with a big, right-drifting
if, but the rest were loops that would have benefited from proper
ret/cont/break support. So yeah, it's not all roses, but I'd argue
that huge blocks aren't very good style, and they might benefit from
being factored into a few top-level functions.
[1]: https://github.com/mozilla/rust/issues/1619
Best,
Marijn
_______________________________________________
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
