[rust-dev] Partial meeting agenda - older RFCs

Gábor Lehel glaebhoerl at gmail.com
Thu Jul 3 07:29:04 PDT 2014


On Wed, Jul 2, 2014 at 8:56 PM, Brian Anderson <banderson at mozilla.com>
wrote:

>
> On 07/02/2014 11:19 AM, Gábor Lehel wrote:
>
>      Thanks, this is a good step, as is delaying taking actions by a day
> as proposed in the meeting itself.
>
>
>  If you have any suggestions for how this regular email or the process in
>> general could be improved, please let us know.
>
>
>  Most fundamentally, what I'm wondering is, why do most of the things
> discussed at the meetings need to be discussed separately in the first
> place?
>
> Why not have those discussions directly in the comments for the respective
> RFC PRs? Up to and including leaving comments like "we suggest closing
> this, because {justification}, unless someone convinces us otherwise", "we
> suggest merging this because {justification}", and so on. In an ideal
> world, the meetings could merely ratify the decisions which were already
> evident from the PR discussions themselves. This could also help avoid
> situations where the two discussions end up disjoint in some way, e.g.
> according to this week's meeting notes @pcwalton and @aturon essentially
> recapitulated the exact same debate about the lifetime elision "self rule"
> at the meeting which @aturon and I had previously gone through in the PR
> comments.
>
>
> I would like to move in this direction, but like many cultural changes it
> will be gradual. The primary reason we do so much in meetings is because
> face-to-face discussions move much faster and involve much less
> argumentation than asynchronous online discussions. In the immediate future
> I'd like to put more pressure on meeting participants to express their
> opinions on the issue ahead of meetings, which this initiative Nick is
> working on helps by making it clear what issues are coming up.
>

Excellent, thanks. I definitely agree about face-to-face discussions being
so much easier.


>
>
>
>
>  From the proposed-for-discussion list:
>
> 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.
>>
>
>  The two are complementary, not substitutive. 122 allows factoring out
> type parameter lists for multiple declarations. 135 allows writing them
> differently.
>
>
>  From the meeting itself, because it concerns process:
>
>>
>>    - nrc: Do we want to keep this open? It's the <> to [] changes.
>>    - acrichto: It's so new, I don't think we should close it.
>>    - nrc: Even so, if we're not going to do it, I don't think we should
>>    keep it open.
>>
>>  I don't see what could have been gained by closing it. Potential
> scenarios if it's left open:
>
>   (1) Participants end up convincing each other than the change is not
> worth doing. (This is what ended up happening in this case.)
>   (2) Contrary to expectations, a consensus emerges in favor of the
> change. Maybe there is some factor that hadn't been taken into account
> previously, or the arguments of one side end up convincing the other. I
> think this might be useful information to have learned. Then you can
> evaluate the decision on the merits.
>
>  Whereas if it's closed early:
>
>   (3) People are left with the opinions they already had, and now might
> also have the impression that Mozilla has heavy-handedly shut down the
> debate.
>
>  I mean, possibly leave a comment like "Just so you know, we are extremely
> unlikely to do this, but feel free to keep discussing", but I think that
> was clear to everyone at the outset. I just don't see what could have been
> gained by preventing the discussion from playing itself out.
>
>  Cheers,
>  Gábor
>
>
>
> On Tue, Jul 1, 2014 at 1:23 AM, Nick Cameron <lists at ncameron.org> wrote:
>
>> 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.
>>
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
>
> _______________________________________________
> Rust-dev mailing listRust-dev at mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
>
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140703/3748826c/attachment.html>


More information about the Rust-dev mailing list