Merge remote-tracking branch 'origin/master' into anonymous-impl

0000-template.md

@@ -1,6 +1,6 @@
 - Start Date: (fill me in with today's date, YYYY-MM-DD)
-- RFC PR #: (leave this empty)
-- Rust Issue #: (leave this empty)
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
 
 # Summary
 

README.md

@@ -19,6 +19,7 @@ changes to the Rust distribution. What constitutes a "substantial"
 change is evolving based on community norms, but may include the following.
 
    - Any semantic or syntactic change to the language that is not a bugfix.
+   - Removing language features, including those that are feature-gated.
    - Changes to the interface between the compiler and libraries, 
 including lang items and intrinsics.
    - Additions to `std`
@@ -57,16 +58,92 @@ comments.
 merging the pull request and assigning the RFC a number, at which point 
 the RFC is 'active', or reject it by closing the pull request.
 
+## The RFC life-cycle
+
 Once an RFC becomes active then authors may implement it and submit the 
 feature as a pull request to the Rust repo. An 'active' is not a rubber 
 stamp, and in particular still does not mean the feature will ultimately 
 be merged; it does mean that in principle all the major stakeholders 
 have agreed to the feature and are amenable to merging it.
 
-Modifications to active RFC's can be done in followup PR's. An RFC that 
-makes it through the entire process to implementation is considered 
-'complete' and is moved to the 'complete' folder; an RFC that fails 
-after becoming active is 'inactive' and moves to the 'inactive' folder.
+Furthermore, the fact that a given RFC has been accepted and is
+'active' implies nothing about what priority is assigned to its
+implementation, nor does it imply anything about whether a Rust
+developer has been assigned the task of implementing the feature.
+
+Modifications to active RFC's can be done in followup PR's.  We strive
+to write each RFC in a manner that it will reflect the final design of
+the feature; but the nature of the process means that we cannot expect
+every merged RFC to actually reflect what the end result will be at
+the time of the next major release; therefore we try to keep each RFC
+document somewhat in sync with the language feature as planned,
+tracking such changes via followup pull requests to the document.
+
+An RFC that makes it through the entire process to implementation is
+considered 'complete' and is moved to the 'complete' folder; an RFC
+that fails after becoming active is 'inactive' and moves to the
+'inactive' folder.
+
+## Implementing an RFC
+
+Some accepted RFC's represent vital features that need to be
+implemented right away. Other accepted RFC's can represent features
+that can wait until some arbitrary developer feels like doing the
+work. Every accepted RFC has an associated issue tracking its
+implementation in the Rust repository; thus that associated issue can
+be assigned a priority via the [triage process] that the team uses for
+all issues in the Rust repository.
+
+The author of an RFC is not obligated to implement it. Of course, the
+RFC author (like any other developer) is welcome to post an
+implementation for review after the RFC has been accepted.
+
+If you are interested in working on the implementation for an 'active'
+RFC, but cannot determine if someone else is already working on it,
+feel free to ask (e.g. by leaving a comment on the associated issue).
+
+## Reviewing RFC's
+
+Each week the [core team] will attempt to review some set of open RFC
+pull requests.  The choice of pull requests to review is largely
+driven by an informal estimate of whether its associated comment
+thread has reached a steady state (i.e. either died out, or not
+showing any sign of providing feedback improvements to the RFC
+itself). The list of RFC's up for review is posted a week ahead of
+time via standard notification channels (currently the 'rust-dev'
+mailing list as well as the http://discuss.rust-lang.org/ discourse
+site).
+
+We try to make sure that any RFC that we accept is accepted at the
+Tuesday team meeting, with a formal record of discussion regarding
+acceptance.  We do not accept RFC’s at the Thursday triage meeting.
+We may reject RFC’s at either meeting; in other words, the only RFC
+activity on Thursdays is closing the ones that have reached a steady
+state and that the team agrees we will not be adopting.
+
+At both meetings, we try to only consider RFC’s for which at least a
+few participants have read the corresponding discussion thread and are
+prepared to represent the viewpoints presented there. One participant
+should act as a "champion" for the feature.  The "champion" need not
+*personally* desire the feature; they just need to act to represent
+its virtues and the community’s desire for it.
+
+## RFC Postponement
+
+Some RFC pull requests are tagged with the 'postponed' label when they
+are closed (as part of the rejection process).  An RFC closed with
+“postponed” is marked as such because we want neither to think about
+evaluating the proposal nor about implementing the described feature
+until after the next major release, and we believe that we can afford
+to wait until then to do so.
+
+Usually an RFC pull request marked as “postponed” has already passed
+an informal first round of evaluation, namely the round of “do we
+think we would ever possibly consider making this change, as outlined
+in the RFC pull request, or some semi-obvious variation of it.”  (When
+the answer to the latter question is “no”, then the appropriate
+response is to close the RFC, not postpone it.)
+
 
 ### Help this is all too informal!
 
@@ -76,3 +153,4 @@ driven by consensus and community norms, not impose more structure than
 necessary.
 
 [core team]: https://github.com/mozilla/rust/wiki/Note-core-team
+[triage process]: https://github.com/rust-lang/rust/wiki/Note-development-policy#milestone-and-priority-nomination-and-triage

active/0001-rfc-process.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-03-11
-- RFC PR #: 2, 6
-- Rust Issue #: N/A
+- 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)
+- Rust Issue: N/A
 
 # Summary
 
@@ -34,6 +34,7 @@ changes to the Rust distribution. What constitutes a "substantial"
 change is evolving based on community norms, but may include the following.
 
    - Any semantic or syntactic change to the language that is not a bugfix.
+   - Removing language features, including those that are feature-gated.
    - Changes to the interface between the compiler and libraries,
 including lang items and intrinsics.
    - Additions to `std`
@@ -59,7 +60,7 @@ RFC merged into the RFC repo as a markdown file. At that point the RFC
 is 'active' and may be implemented with the goal of eventual inclusion
 into Rust.
 
-* Fork the RFC repo http://github.com/rust-lang/rfcs
+* Fork the RFC repo https://github.com/rust-lang/rfcs
 * Copy `0000-template.md` to `active/0000-my-feature.md` (where
 'my-feature' is descriptive. don't assign an RFC number yet).
 * Fill in the RFC

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

@@ -1,6 +1,6 @@
 - Start Date: 2014-03-24
-- RFC PR #: 19
-- Rust Issue #: 13231
+- RFC PR: [rust-lang/rfcs#19](https://github.com/rust-lang/rfcs/pull/19)
+- Rust Issue: [rust-lang/rust#13231](https://github.com/rust-lang/rust/issues/13231)
 
 # Summary
 

active/0005-new-intrinsics.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-03-14
-- RFC PR #: 8
-- Rust Issue #: (leave this empty)
+- RFC PR: [rust-lang/rfcs#8](https://github.com/rust-lang/rfcs/pull/8)
+- Rust Issue: 
 
 # Summary
 

active/0011-bounded-type-parameters.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-04-05
-- RFC PR #:
-- Rust Issue #:
+- RFC PR:
+- Rust Issue:
 
 # Summary
 

active/0018-undefined-struct-layout.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-05-17
-- RFC PR #: 79
-- Rust Issue #: 14309
+- RFC PR: [rust-lang/rfcs#79](https://github.com/rust-lang/rfcs/pull/79)
+- Rust Issue: [rust-lang/rust#14309](https://github.com/rust-lang/rust/issues/14309)
 
 # Summary
 

active/0021-lexical-syntax-simplification.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-05-23
-- RFC PR #: 90
-- Rust Issue #: 14504
+- RFC PR: [rust-lang/rfcs#90](https://github.com/rust-lang/rfcs/pull/90)
+- Rust Issue: [rust-lang/rust#14504](https://github.com/rust-lang/rust/issues/14504)
 
 # Summary
 

active/0024-traits.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-06-10
-- RFC PR #: 48
-- Rust Issue #: 5527
+- RFC PR: [rust-lang/rfcs#48](https://github.com/rust-lang/rfcs/pull/48)
+- Rust Issue: [rust-lang/rust#5527](https://github.com/rust-lang/rust/issues/5527)
 
 # Summary
 

active/0031-better-temporary-lifetimes.md

@@ -1,6 +1,6 @@
 - Start Date: 2014-05-04
-- RFC PR #: 0031
-- Rust Issue #: 15023
+- RFC PR: [rust-lang/rfcs#0031](https://github.com/rust-lang/rfcs/pull/0031)
+- Rust Issue: [rust-lang/rust#15023](https://github.com/rust-lang/rust/issues/15023)
 
 # Summary
 

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

@@ -1,6 +1,6 @@
 - Start Date: 2014-06-05
-- RFC PR #: 107
-- Rust Issue #: 15287
+- RFC PR: [rust-lang/rfcs#107](https://github.com/rust-lang/rfcs/pull/107)
+- Rust Issue: [rust-lang/rust#15287](https://github.com/rust-lang/rust/issues/15287)
 
 # Summary
 

active/0038-capture-by-value.md

@@ -0,0 +1,33 @@
+- Start Date: 2014-07-02
+- RFC PR: [rust-lang/rfcs#151](https://github.com/rust-lang/rfcs/pull/151)
+- Rust Issue: [rust-lang/rust#12831](https://github.com/rust-lang/rust/issues/12831)
+
+# Summary
+
+Closures should capture their upvars by value unless the `ref` keyword is used.
+
+# Motivation
+
+For unboxed closures, we will need to syntactically distinguish between captures by value and captures by reference.
+
+# Detailed design
+
+This is a small part of #114, split off to separate it from the rest of the discussion going on in that RFC.
+
+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.
+
+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.
+
+# Drawbacks
+
+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.
+
+# Alternatives
+
+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.
+
+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.
+
+# Unresolved questions
+
+None.