<div dir="ltr">Hi all, there have recently been some calls to be more open about the Rust meetings, in particular to publish the agenda beforehand. The agenda setting has been quite informal, often not coming together until the meeting starts. Not to say that we won't publish an agenda in the future, but that it is not as easy as it might seem. However, as a step towards that, I will be mailing out the part of the agenda that is set in advance which is the set of (usually older) RFCs where discussion has mostly ceased and where we feel we can make a decision on progress. This email is a relatively new convention in any case. It has been sent to most meeting attendees at the start of the week. From now on, I'll send it to the mailing list instead. If you have comments on the RFCs, please comment on the RFC PR itself, please do not reply to the mailing list. <br>
<br>Some explanation of the process here - each week there are two Rust meetings where we discuss RFCs, the general Rust meeting and the triage meeting. We only accept RFCs at the general meeting. RFCs may be closed at either meeting. In order to make sure no older RFCs slip through the cracks, RFCs where discussion has come to a stop (or nearly so) are recommended each week for discussion. Based on the outcome of the discussion on the PR and the current goals of the Rust project (in particular in not accepting any major backwards compatible changes before 1.0) an RFC will be proposed for discussion at the general meeting if it needs discussion or we are likely to accept, or to the triage meeting if it is likely to closed. To clarify, what actually happens to an RFC is decided at the meeting, not by which meeting it is discussed at. Often, other RFCs are also discussed at the meetings where attendees think there is a more urgent need to discuss something. You can see the minutes of the meeting discussions at <a href="https://github.com/rust-lang/meeting-minutes">https://github.com/rust-lang/meeting-minutes</a>. Not all the RFCs proposed in this email get discussed at the meetings - either because we run out of time or because a key person is not at the meeting.<br>
<br>The 'actions agreed' section keeps track of actions on older RFCs agreed at previous meetings, but which have not yet been carried out.<br><br>If you have any suggestions for how this regular email or the process in general could be improved, please let us know.<br>
<br>Cheers, Nick<br><br><br>Proposed for discussion at Rust meeting<br>---------------------------------------<br><br><a href="https://github.com/rust-lang/rfcs/pull/16">https://github.com/rust-lang/rfcs/pull/16</a> - attributes on statements and blocks<br>
    huon has updated<br>    should we accept now?<br><br><a href="https://github.com/rust-lang/rfcs/pull/17">https://github.com/rust-lang/rfcs/pull/17</a> - Iterable trait family - erikt<br>    No recommendation, just needs a kick to get moving again.<br>
<br><a href="https://github.com/rust-lang/rfcs/pull/108">https://github.com/rust-lang/rfcs/pull/108</a> - Convenience syntax for module imports - tommit<br>    Allow e.g., `use module::{self, Type};` for `use module::Type; use module;`.<br>
    Generally positive response. Some bike shedding around the use of `self` since we call the file <a href="http://mod.rs">mod.rs</a>, and some proposal to allow <a href="http://self.rs">self.rs</a> instead.<br>    Recommend we accept (possibly we should bikeshed the synax `self`). We could postpone this (it would be backwards compatible), but it seems very desirable and would be little effort to implement.<br>
<br><a href="https://github.com/rust-lang/rfcs/pull/114">https://github.com/rust-lang/rfcs/pull/114</a> - Unboxed closures - nmatsakis<br>    A lot of discussion, pretty much all about the details. General sentiment that we want this.<br>
    Recommend we accept - is this the right RFC to accept, I've not really been keeping track - pnkfelix, pcwalton - is there something which supersedes this? I think this needs a small update to reflect some of the later comments.<br>
<br><a href="https://github.com/rust-lang/rfcs/pull/117">https://github.com/rust-lang/rfcs/pull/117</a> - Rename unsafe to trusted - stevelabnik<br>    Loads of opinion in the thread (162 comments!). Note that Niko has an upcoming RFC with the concept of unsafe/trusted traits where the keyword `trusted` makes a lot more sense than `unsafe`, so we could save a keyword here.<br>
    Recommend we discuss this.<br><br><a href="https://github.com/rust-lang/rfcs/pull/118">https://github.com/rust-lang/rfcs/pull/118</a> - arithmetics and logic operators to take their arguments by value not by ref - pcwalton.<br>
    Pretty negative feedback (though not all). I remember being convinced this was the proper way to implement arithmetic operators a while back, but I can't remember why (something about using tuples in the signature maybe? I can't remember). There seems to be some poor interaction with BigInt, etc. where implementing for `&BigInt` isn't what you want (but I don't see why from the comment, pcwalton seems to in his reply though).<br>
    Lets discuss this.<br><br><br>Proposed for discussion at triage<br>---------------------------------<br><br><a href="https://github.com/rust-lang/rfcs/pull/98">https://github.com/rust-lang/rfcs/pull/98</a> - Add 'maybe initialised' pointers (pretty much out params, aiui) - gereeter<br>
    A new form of reference, `&uninit`, is added that is write-only and points to possibly uninitialized data.<br>    Mixed reactions - overall positive, but agreement on low priority.<br>    Recommend close as postponed - was this agreed last week?<br>
<br><a href="https://github.com/rust-lang/rfcs/pull/45">https://github.com/rust-lang/rfcs/pull/45</a> - Avoiding integer overflow - bmyers<br>    Proposes range types and other complicated stuff, but discusses other options.<br>
    Lots of discussion on integer overflow in general, no agreement. Also discussed to death on the mailing list several times, including currently.<br>    Recommend close - we might conceivably do something, but we won't do this and we won't lose anything by closing this RFC (there's also a new RFC with a different proposal derived from the most recent mailing list thread).<br>
<br><a href="https://github.com/rust-lang/rfcs/pull/119">https://github.com/rust-lang/rfcs/pull/119</a> - add support to serialize::json for incrementally reading multiple JSON objects - XMPPwocky<br>    Apparently this is included in RFC 22, which has an implementation.<br>
    Recommend close in deference to RFC 22.<br><br><a href="https://github.com/rust-lang/rfcs/pull/120">https://github.com/rust-lang/rfcs/pull/120</a> - Reintroduce 'do' keyword as sugar for nested match statements - bvssvni<br>
    Syntax for flattening match statements by 'chaining' arms of a match statement.<br>    Feedback is mostly negative. Some positive feelings for including the macro rather than first class syntax. Others want to wait for HKT and have a function.<br>
    Recommend close as postponed. We probably want something like this, but not pre-1.0.<br><br><a href="https://github.com/rust-lang/rfcs/pull/122">https://github.com/rust-lang/rfcs/pull/122</a> - Syntax sugar for prefix-style type parameter lists - ben0x539<br>
    Sugary syntax for putting a group of type parameters and their bounds before a group of functions. Motivation is our often unwieldly lists of type parameters.<br>    Not much feedback, but mostly positive. Generally for the motivation, rather than the solution.<br>
    Recommend close in deference to RFC 135 (where clauses) which solve the motivating problem here, along with other issues.<br><br><br>Actions agreed<br>--------------<br><br><a href="https://github.com/rust-lang/rfcs/pull/22">https://github.com/rust-lang/rfcs/pull/22</a> - Deserializing to a stream of tagged values - erikt<br>
    Changes to the deserialisation framework. Allows for decoding into an enum. No commentary for or against.<br>    erikt to update?<br><br><a href="https://github.com/rust-lang/rfcs/pull/88">https://github.com/rust-lang/rfcs/pull/88</a> - Macro syntax to count sequence repetitions - Eridius<br>
    More discussion - esp, can it be done with a macro<br><br><a href="https://github.com/rust-lang/rfcs/pull/101">https://github.com/rust-lang/rfcs/pull/101</a> - More flexible pattern matching for slices - krdln<br>    No comments. The RFC is a little bit vague, but seems like kind of a win. Backwards incompatible.<br>
    Close.<br><br></div>