[rust-dev] RFC: Future-proof for unboxed closures

Brian Anderson banderson at mozilla.com
Thu Jan 2 15:04:22 PST 2014

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 

> 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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev

More information about the Rust-dev mailing list