I think the situation is somewhat more complex than you suggest.
First, heap-based closures like fn@ and fn~ copy values from the
environment at the point of creation. This is particularly relevant for
mutable variables. To allow for mutual recursion, we would need some
sort of expression fo
Le 13/07/2012 21:42, Patrick Walton a écrit :
> On 7/13/12 12:38 PM, David Bruant wrote:
>> I can't help but asking why can't named function close over their
>> environment?
>> In the case above, I see no harm in allowing the 'bar' function to
>> access 'foo'.
>
> Because named functions are always
On 7/13/12 12:38 PM, David Bruant wrote:
I can't help but asking why can't named function close over their
environment?
In the case above, I see no harm in allowing the 'bar' function to
access 'foo'.
Because named functions are always in scope (they're always mutually
recursive), while locals
Hi,
Looking at the Rust documentation, I read:
Named functions, like those we've seen so far, may not refer to local
variables decalared outside the function - they do not "close over their
environment". For example you couldn't write the following:
let foo = 10;
fn bar() -> int {
ret fo
