On 12/30/2013 01:11 PM, Patrick Walton wrote:
I've been thinking that to future-proof unboxed closures in the future
we should maybe limit `|x| x+1` lambda syntax to either (a) require
`&` in front or (b) in function position.
So today you would write:
let f = |x| x+1;
But tomorrow you would write:
let f = &|x| x+1;
But it would always work here:
v.map(|&x| x+1);
The reason is simply that we'd like `|x| x+1` to become an unboxed
closure in the future and it's easier in the language semantics to
future-proof for it this way: we simply special-case the function
argument position.
Why special case it in argument position instead of just requiring &
everywhere? Also, why couldn't you pass the closure by value to another
function?
Alternatively we can do it with assignability: say that `|x| x+1` is
an anonymous type (an error today) that is assignable to the type
`|int|->int`. That might be cleaner than special-casing the function
argument position.
Patrick
_______________________________________________
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
