Patrick Walton wrote:
>> (2) All named functions have type "@fn". They are reference counted. They
>> can close over outer variables, but only those on the heap (i.e. only over
>> boxes).
Note that there are a few ways this could be achieved.
a) C++0x-style capture clauses:
{
let x = @99;
let f = @fn() [x] { ret *x + 1; };
x = @666;
log f(); // 100
}
b) Manual closure-conversion with bind:
{
let x = @99;
let f = bind @fn(x) { ret *x + 1; }(x);
x = @666;
log f(); // 100
}
c) Implicit copying:
{
let x = @99;
let f = @fn() { ret *x + 1; };
x = @666;
log f(); // 100
}
d) Explicit Java-style const restriction:
{
const x = @99;
let f = @fn() { ret *x + 1; };
x = @666; // ***TYPE ERROR: x is const***
log f();
}
e) Implicit Java-style const restriction:
{
let x = @99;
let f = @fn() { ret *x + 1; };
x = @666; // ***TYPE ERROR: x is closed over and must be const***
log f();
}
Marijn Haverbeke wrote:
> Would it be a problem to also allow them to close over copyable
> locals, and simply copy them? That seems like it'd be very convenient.
> (Though the difference between closing by-value and by-reference will
> occasionally confuse a newcomer.)
I'm a little nervous about the implicit copying ideas, whether for interior
stack data or stack-local pointers to heap data. We've tried to avoid
surprising copies. C++0x is clunky but at least it makes copying an explicit
operation. Also, having upvars evaluated (dereferenced) at the time the
function is created, rather than when it's called, seems strange to me, but
maybe that's just because of my Lispy background.
Dave
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
