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
O
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
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
Hi everyone
I was just wondering why returns from block functions have been banned?
Possibly I'm writing code in an unusual style, but I have some fairly long
block functions - being able to use 'ret' to immediately return feels quite
a bit nicer than having to arrange things so that the block its
