[rust-dev] Partial meeting agenda - older RFCs

Nick Cameron lists at ncameron.org
Mon Jun 30 16:23:04 PDT 2014


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.

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 https://github.com/rust-lang/meeting-minutes. 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.

The 'actions agreed' section keeps track of actions on older RFCs agreed at
previous meetings, but which have not yet been carried out.

If you have any suggestions for how this regular email or the process in
general could be improved, please let us know.

Cheers, Nick


Proposed for discussion at Rust meeting
---------------------------------------

https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and
blocks
    huon has updated
    should we accept now?

https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt
    No recommendation, just needs a kick to get moving again.

https://github.com/rust-lang/rfcs/pull/108 - Convenience syntax for module
imports - tommit
    Allow e.g., `use module::{self, Type};` for `use module::Type; use
module;`.
    Generally positive response. Some bike shedding around the use of
`self` since we call the file mod.rs, and some proposal to allow self.rs
instead.
    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.

https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis
    A lot of discussion, pretty much all about the details. General
sentiment that we want this.
    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.

https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted -
stevelabnik
    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.
    Recommend we discuss this.

https://github.com/rust-lang/rfcs/pull/118 - arithmetics and logic
operators to take their arguments by value not by ref - pcwalton.
    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).
    Lets discuss this.


Proposed for discussion at triage
---------------------------------

https://github.com/rust-lang/rfcs/pull/98 - Add 'maybe initialised'
pointers (pretty much out params, aiui) - gereeter
    A new form of reference, `&uninit`, is added that is write-only and
points to possibly uninitialized data.
    Mixed reactions - overall positive, but agreement on low priority.
    Recommend close as postponed - was this agreed last week?

https://github.com/rust-lang/rfcs/pull/45 - Avoiding integer overflow -
bmyers
    Proposes range types and other complicated stuff, but discusses other
options.
    Lots of discussion on integer overflow in general, no agreement. Also
discussed to death on the mailing list several times, including currently.
    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).

https://github.com/rust-lang/rfcs/pull/119 - add support to serialize::json
for incrementally reading multiple JSON objects - XMPPwocky
    Apparently this is included in RFC 22, which has an implementation.
    Recommend close in deference to RFC 22.

https://github.com/rust-lang/rfcs/pull/120 - Reintroduce 'do' keyword as
sugar for nested match statements - bvssvni
    Syntax for flattening match statements by 'chaining' arms of a match
statement.
    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.
    Recommend close as postponed. We probably want something like this, but
not pre-1.0.

https://github.com/rust-lang/rfcs/pull/122 - Syntax sugar for prefix-style
type parameter lists - ben0x539
    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.
    Not much feedback, but mostly positive. Generally for the motivation,
rather than the solution.
    Recommend close in deference to RFC 135 (where clauses) which solve the
motivating problem here, along with other issues.


Actions agreed
--------------

https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of
tagged values - erikt
    Changes to the deserialisation framework. Allows for decoding into an
enum. No commentary for or against.
    erikt to update?

https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence
repetitions - Eridius
    More discussion - esp, can it be done with a macro

https://github.com/rust-lang/rfcs/pull/101 - More flexible pattern matching
for slices - krdln
    No comments. The RFC is a little bit vague, but seems like kind of a
win. Backwards incompatible.
    Close.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140701/a6773d6c/attachment.html>


More information about the Rust-dev mailing list