Wouldn't it have to be `&mut` rather than `&` to fit the semantics of | |, which is affine and can mutate its environment?
And wouldn't this lead to divergence between the type- and value syntax, with | | as a type being a boxed closure (`&mut FnMut`), and an unboxed closure as a value? This was one of the nicer points of the recent closure overhaul, and it would be a shame to lose it so soon. On Mon, Dec 30, 2013 at 10:11 PM, Patrick Walton <[email protected]>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. > > 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
