Yes, it would need to be &mut, you're right.
I think the underlying type syntax would be something like `Fn<int,&int>` for
the unboxed version, and `&mut Fn<int,&int>` for the boxed version. The type
syntax with the bars is just syntactic sugar for the latter (and, in trait
bound position, for the former).
It's somewhat unfortunate but I don't see a particularly good alternative if we
want boxed and unboxed closures alike to have nice-looking APIs. The
alternative, I guess, is to block 1.0 on unboxed closures, convert all our APIs
to unboxed closures where possible, and just say that if you want a boxed
closure you have to write `&mut |x| x + 1` at each closure construction site...
Patrick
"Gábor Lehel" <[email protected]> wrote:
>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
>>
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
