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.
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 <li...@ncameron.org
<mailto:li...@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 <http://mod.rs>, and some
proposal to allow self.rs <http://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@mozilla.org <mailto:Rust-dev@mozilla.org>
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
