Skip to content

Commit 8e4c530

Browse files
pcwaltonpcwalton
committed
Merge remote-tracking branch 'origin/master' into anonymous-impl
2 parents d38d12d + 4c5a73d commit 8e4c530

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

55 files changed

+3737
-75
lines changed

‎0000-template.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: (fill me in with today's date, YYYY-MM-DD)
2-
- RFC PR #: (leave this empty)
3-
- Rust Issue #: (leave this empty)
2+
- RFC PR: (leave this empty)
3+
- Rust Issue: (leave this empty)
44

55
# Summary
66

‎README.md

Lines changed: 82 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@ changes to the Rust distribution. What constitutes a "substantial"
1919
change is evolving based on community norms, but may include the following.
2020

2121
- Any semantic or syntactic change to the language that is not a bugfix.
22+
- Removing language features, including those that are feature-gated.
2223
- Changes to the interface between the compiler and libraries,
2324
including lang items and intrinsics.
2425
- Additions to `std`
@@ -57,16 +58,92 @@ comments.
5758
merging the pull request and assigning the RFC a number, at which point
5859
the RFC is 'active', or reject it by closing the pull request.
5960

61+
## The RFC life-cycle
62+
6063
Once an RFC becomes active then authors may implement it and submit the
6164
feature as a pull request to the Rust repo. An 'active' is not a rubber
6265
stamp, and in particular still does not mean the feature will ultimately
6366
be merged; it does mean that in principle all the major stakeholders
6467
have agreed to the feature and are amenable to merging it.
6568

66-
Modifications to active RFC's can be done in followup PR's. An RFC that
67-
makes it through the entire process to implementation is considered
68-
'complete' and is moved to the 'complete' folder; an RFC that fails
69-
after becoming active is 'inactive' and moves to the 'inactive' folder.
69+
Furthermore, the fact that a given RFC has been accepted and is
70+
'active' implies nothing about what priority is assigned to its
71+
implementation, nor does it imply anything about whether a Rust
72+
developer has been assigned the task of implementing the feature.
73+
74+
Modifications to active RFC's can be done in followup PR's. We strive
75+
to write each RFC in a manner that it will reflect the final design of
76+
the feature; but the nature of the process means that we cannot expect
77+
every merged RFC to actually reflect what the end result will be at
78+
the time of the next major release; therefore we try to keep each RFC
79+
document somewhat in sync with the language feature as planned,
80+
tracking such changes via followup pull requests to the document.
81+
82+
An RFC that makes it through the entire process to implementation is
83+
considered 'complete' and is moved to the 'complete' folder; an RFC
84+
that fails after becoming active is 'inactive' and moves to the
85+
'inactive' folder.
86+
87+
## Implementing an RFC
88+
89+
Some accepted RFC's represent vital features that need to be
90+
implemented right away. Other accepted RFC's can represent features
91+
that can wait until some arbitrary developer feels like doing the
92+
work. Every accepted RFC has an associated issue tracking its
93+
implementation in the Rust repository; thus that associated issue can
94+
be assigned a priority via the [triage process] that the team uses for
95+
all issues in the Rust repository.
96+
97+
The author of an RFC is not obligated to implement it. Of course, the
98+
RFC author (like any other developer) is welcome to post an
99+
implementation for review after the RFC has been accepted.
100+
101+
If you are interested in working on the implementation for an 'active'
102+
RFC, but cannot determine if someone else is already working on it,
103+
feel free to ask (e.g. by leaving a comment on the associated issue).
104+
105+
## Reviewing RFC's
106+
107+
Each week the [core team] will attempt to review some set of open RFC
108+
pull requests. The choice of pull requests to review is largely
109+
driven by an informal estimate of whether its associated comment
110+
thread has reached a steady state (i.e. either died out, or not
111+
showing any sign of providing feedback improvements to the RFC
112+
itself). The list of RFC's up for review is posted a week ahead of
113+
time via standard notification channels (currently the 'rust-dev'
114+
mailing list as well as the http://discuss.rust-lang.org/ discourse
115+
site).
116+
117+
We try to make sure that any RFC that we accept is accepted at the
118+
Tuesday team meeting, with a formal record of discussion regarding
119+
acceptance. We do not accept RFC’s at the Thursday triage meeting.
120+
We may reject RFC’s at either meeting; in other words, the only RFC
121+
activity on Thursdays is closing the ones that have reached a steady
122+
state and that the team agrees we will not be adopting.
123+
124+
At both meetings, we try to only consider RFC’s for which at least a
125+
few participants have read the corresponding discussion thread and are
126+
prepared to represent the viewpoints presented there. One participant
127+
should act as a "champion" for the feature. The "champion" need not
128+
*personally* desire the feature; they just need to act to represent
129+
its virtues and the community’s desire for it.
130+
131+
## RFC Postponement
132+
133+
Some RFC pull requests are tagged with the 'postponed' label when they
134+
are closed (as part of the rejection process). An RFC closed with
135+
“postponed” is marked as such because we want neither to think about
136+
evaluating the proposal nor about implementing the described feature
137+
until after the next major release, and we believe that we can afford
138+
to wait until then to do so.
139+
140+
Usually an RFC pull request marked as “postponed” has already passed
141+
an informal first round of evaluation, namely the round of “do we
142+
think we would ever possibly consider making this change, as outlined
143+
in the RFC pull request, or some semi-obvious variation of it.” (When
144+
the answer to the latter question is “no”, then the appropriate
145+
response is to close the RFC, not postpone it.)
146+
70147

71148
### Help this is all too informal!
72149

@@ -76,3 +153,4 @@ driven by consensus and community norms, not impose more structure than
76153
necessary.
77154

78155
[core team]: https://github.com/mozilla/rust/wiki/Note-core-team
156+
[triage process]: https://github.com/rust-lang/rust/wiki/Note-development-policy#milestone-and-priority-nomination-and-triage

‎active/0001-rfc-process.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-03-11
2-
- RFC PR #: 2, 6
3-
- Rust Issue #: N/A
2+
- RFC PR: [rust-lang/rfcs#2](https://github.com/rust-lang/rfcs/pull/2), [rust-lang/rfcs#6](https://github.com/rust-lang/rfcs/pull/6)
3+
- Rust Issue: N/A
44

55
# Summary
66

@@ -34,6 +34,7 @@ changes to the Rust distribution. What constitutes a "substantial"
3434
change is evolving based on community norms, but may include the following.
3535

3636
- Any semantic or syntactic change to the language that is not a bugfix.
37+
- Removing language features, including those that are feature-gated.
3738
- Changes to the interface between the compiler and libraries,
3839
including lang items and intrinsics.
3940
- Additions to `std`
@@ -59,7 +60,7 @@ RFC merged into the RFC repo as a markdown file. At that point the RFC
5960
is 'active' and may be implemented with the goal of eventual inclusion
6061
into Rust.
6162

62-
* Fork the RFC repo http://github.com/rust-lang/rfcs
63+
* Fork the RFC repo https://github.com/rust-lang/rfcs
6364
* Copy `0000-template.md` to `active/0000-my-feature.md` (where
6465
'my-feature' is descriptive. don't assign an RFC number yet).
6566
* Fill in the RFC

‎active/0003-opt-in-builtin-traits.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-03-24
2-
- RFC PR #: 19
3-
- Rust Issue #: 13231
2+
- RFC PR: [rust-lang/rfcs#19](https://github.com/rust-lang/rfcs/pull/19)
3+
- Rust Issue: [rust-lang/rust#13231](https://github.com/rust-lang/rust/issues/13231)
44

55
# Summary
66

‎active/0005-new-intrinsics.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-03-14
2-
- RFC PR #: 8
3-
- Rust Issue #: (leave this empty)
2+
- RFC PR: [rust-lang/rfcs#8](https://github.com/rust-lang/rfcs/pull/8)
3+
- Rust Issue:
44

55
# Summary
66

‎active/0011-bounded-type-parameters.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-04-05
2-
- RFC PR #:
3-
- Rust Issue #:
2+
- RFC PR:
3+
- Rust Issue:
44

55
# Summary
66

‎active/0018-undefined-struct-layout.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-05-17
2-
- RFC PR #: 79
3-
- Rust Issue #: 14309
2+
- RFC PR: [rust-lang/rfcs#79](https://github.com/rust-lang/rfcs/pull/79)
3+
- Rust Issue: [rust-lang/rust#14309](https://github.com/rust-lang/rust/issues/14309)
44

55
# Summary
66

‎active/0021-lexical-syntax-simplification.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-05-23
2-
- RFC PR #: 90
3-
- Rust Issue #: 14504
2+
- RFC PR: [rust-lang/rfcs#90](https://github.com/rust-lang/rfcs/pull/90)
3+
- Rust Issue: [rust-lang/rust#14504](https://github.com/rust-lang/rust/issues/14504)
44

55
# Summary
66

‎active/0024-traits.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-06-10
2-
- RFC PR #: 48
3-
- Rust Issue #: 5527
2+
- RFC PR: [rust-lang/rfcs#48](https://github.com/rust-lang/rfcs/pull/48)
3+
- Rust Issue: [rust-lang/rust#5527](https://github.com/rust-lang/rust/issues/5527)
44

55
# Summary
66

‎active/0031-better-temporary-lifetimes.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-05-04
2-
- RFC PR #: 0031
3-
- Rust Issue #: 15023
2+
- RFC PR: [rust-lang/rfcs#0031](https://github.com/rust-lang/rfcs/pull/0031)
3+
- Rust Issue: [rust-lang/rust#15023](https://github.com/rust-lang/rust/issues/15023)
44

55
# Summary
66

‎active/0036-pattern-guards-with-bind-by-move.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
- Start Date: 2014-06-05
2-
- RFC PR #: 107
3-
- Rust Issue #: 15287
2+
- RFC PR: [rust-lang/rfcs#107](https://github.com/rust-lang/rfcs/pull/107)
3+
- Rust Issue: [rust-lang/rust#15287](https://github.com/rust-lang/rust/issues/15287)
44

55
# Summary
66

‎active/0038-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: [rust-lang/rfcs#151](https://github.com/rust-lang/rfcs/pull/151)
3+
- Rust Issue: [rust-lang/rust#12831](https://github.com/rust-lang/rust/issues/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)