Skip to content

Commit f0fc0af

Browse files
committed
RFC: Capture upvars by value unless the ref keyword is used
1 parent 40f0c43 commit f0fc0af

File tree

1 file changed

+33
-0
lines changed

1 file changed

+33
-0
lines changed

active/0000-capture-by-value.md

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
- Start Date: 2014-07-02
2+
- RFC PR #: (leave this empty)
3+
- Rust Issue #: 12831
4+
5+
# Summary
6+
7+
Closures should capture their upvars by value unless the `ref` keyword is used.
8+
9+
# Motivation
10+
11+
For unboxed closures, we will need to syntactically distinguish between captures by value and captures by reference.
12+
13+
# Detailed design
14+
15+
This is a small part of #114, split off to separate it from the rest of the discussion going on in that RFC.
16+
17+
Closures should capture their upvars (closed-over variables) by value unless the `ref` keyword precedes the opening `|` of the argument list. Thus `|x| x + 2` will capture `x` by value (and thus, if `x` is not `Copy`, it will move `x` into the closure), but `ref |x| x + 2` will capture `x` by reference.
18+
19+
In an unboxed-closures world, the immutability/mutability of the borrow (as the case may be) is inferred from the type of the closure: `Fn` captures by immutable reference, while `FnMut` captures by mutable reference. In a boxed-closures world, the borrows are always mutable.
20+
21+
# Drawbacks
22+
23+
It may be that `ref` is unwanted complexity; it only changes the semantics of 10%-20% of closures, after all. This does not add any core functionality to the language, as a reference can always be made explicitly and then captured. However, there are a *lot* of closures, and the workaround to capture a reference by value is painful.
24+
25+
# Alternatives
26+
27+
As above, the impact of not doing this is that reference semantics would have to be achieved. However, the diff against current Rust was thousands of lines of pretty ugly code.
28+
29+
Another alternative would be to annotate each individual upvar with its capture semantics, like capture clauses in C++11. This proposal does not preclude adding that functionality should it be deemed useful in the future. Note that C++11 provides a syntax for capturing all upvars by reference, exactly as this proposal does.
30+
31+
# Unresolved questions
32+
33+
None.

0 commit comments

Comments
 (0)