Re: [rust-dev] Next week's older RFCs
On Sun, Jul 13, 2014 at 10:37 PM, Nick Cameron wrote: > Yes, this is the right place for meta-discussion. > > I'll make sure to be stricter about commenting on the PRs in the future. > The aim of this email is only to summarise the discussion so far, it > shouldn't add new opinions or comments beyond applying our 'rules' for > accepting PRs in the most uncontroversial manner. Obviously that is kind of > a fuzzy statement, but I think you are right that here I didn't quite stick > to that. Sorry. > Yes, this sounds sensible to me. Thanks for explaining. > > In general, I agree with your last point, but it takes considerable time > and energy to have an active role and that is in limited supply, so it is > always a trade off on whether any particular person gets involved with a > particular RFC. Having said that, the vast majority of the discussion for > an RFC should always be happening on the RFC. > > I can really, really sympathize with the limited time and energy problem, because I have it as well. Following that line of thought, we should consider the fact that most contributors have even less time and energy, and aren't compensated for it. As such, any steps, even incremental, in the direction of a more engaged and collaborative process, as opposed to just an ultimate accept/postpone/reject decision, would be very much appreciated. Cheers > > Cheers, Nick > > > On Mon, Jul 14, 2014 at 2:29 AM, Gábor Lehel wrote: > >> On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: >> >>> https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce >>> universal quantification - glaebhoerl >>> Use `for` rather than `<...>` syntax for type-parametric items. >>> Not much feedback, some discussion. >>> Recommend close - we're not up for changing the syntax of Rust in >>> such a fundamental way at this stage and want to keep with the >>> curly-brace-language heritage. >>> >> >> (Thank you for sending these e-mails. I've responded to the substantive >> aspects of this at the PR, as requested, but for the "meta" aspects >> pertaining to process, I hope that replying to the e-mail is acceptable.) >> >> If I may file a small protest: It feels wrong to me that the first time I >> hear of this concern is in a recommendation to the meeting group to close >> the PR because of it. (Which is not to mention that it's based on a basic >> misunderstanding of the proposal.) Would it be possible to always raise a >> particular concern in the comments on a PR before using it as justification >> to close, or recommend closing, that PR? >> >> (In general, I think it would be beneficial if the people who get to >> decide the fate of PRs took a more active role in discussing and shaping >> them, instead of staying aloof before handing down an opinion at some >> point.) >> >> > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Next week's older RFCs
On 07/10/2014 05:48 PM, Nick Cameron wrote: Hi, here are the recommendations for discussion at next weeks meetings. There is a new section of RFCs which are ready for discussion but discussion has been postponed because we're waiting on a key person for that RFC to be present. This is mostly for RFCs which have been brought up for discussion in a meeting but, we've postponed. There are a few other RFCs not on this list where I've ignored them for now because the right people (mostly Niko) aren't around. So, there a very few RFCs this week that are obvious candidates for closure and I we are pretty much up to date in that respect. There is still quite a backlog of RFCs which we should discuss at meetings and that backlog is only shrinking slowly. I think in general we don't have enough time at the general meeting to discuss more RFCs. Should we start discussing RFCs we might accept at triage? Or are we OK slowly chipping away? Or should we have another meeting or some other solution? The situation doesn't seem dire to me yet. Right now there are 37 RFC PR's open. I don't have a sense of how that compares historically, but Rust has 56, and that's a higher number... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Next week's older RFCs
Yes, this is the right place for meta-discussion. I'll make sure to be stricter about commenting on the PRs in the future. The aim of this email is only to summarise the discussion so far, it shouldn't add new opinions or comments beyond applying our 'rules' for accepting PRs in the most uncontroversial manner. Obviously that is kind of a fuzzy statement, but I think you are right that here I didn't quite stick to that. Sorry. In general, I agree with your last point, but it takes considerable time and energy to have an active role and that is in limited supply, so it is always a trade off on whether any particular person gets involved with a particular RFC. Having said that, the vast majority of the discussion for an RFC should always be happening on the RFC. Cheers, Nick On Mon, Jul 14, 2014 at 2:29 AM, Gábor Lehel wrote: > On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: > >> https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce >> universal quantification - glaebhoerl >> Use `for` rather than `<...>` syntax for type-parametric items. >> Not much feedback, some discussion. >> Recommend close - we're not up for changing the syntax of Rust in >> such a fundamental way at this stage and want to keep with the >> curly-brace-language heritage. >> > > (Thank you for sending these e-mails. I've responded to the substantive > aspects of this at the PR, as requested, but for the "meta" aspects > pertaining to process, I hope that replying to the e-mail is acceptable.) > > If I may file a small protest: It feels wrong to me that the first time I > hear of this concern is in a recommendation to the meeting group to close > the PR because of it. (Which is not to mention that it's based on a basic > misunderstanding of the proposal.) Would it be possible to always raise a > particular concern in the comments on a PR before using it as justification > to close, or recommend closing, that PR? > > (In general, I think it would be beneficial if the people who get to > decide the fate of PRs took a more active role in discussing and shaping > them, instead of staying aloof before handing down an opinion at some > point.) > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Next week's older RFCs
On Fri, Jul 11, 2014 at 2:48 AM, Nick Cameron wrote: > https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce > universal quantification - glaebhoerl > Use `for` rather than `<...>` syntax for type-parametric items. > Not much feedback, some discussion. > Recommend close - we're not up for changing the syntax of Rust in such > a fundamental way at this stage and want to keep with the > curly-brace-language heritage. > (Thank you for sending these e-mails. I've responded to the substantive aspects of this at the PR, as requested, but for the "meta" aspects pertaining to process, I hope that replying to the e-mail is acceptable.) If I may file a small protest: It feels wrong to me that the first time I hear of this concern is in a recommendation to the meeting group to close the PR because of it. (Which is not to mention that it's based on a basic misunderstanding of the proposal.) Would it be possible to always raise a particular concern in the comments on a PR before using it as justification to close, or recommend closing, that PR? (In general, I think it would be beneficial if the people who get to decide the fate of PRs took a more active role in discussing and shaping them, instead of staying aloof before handing down an opinion at some point.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Next week's older RFCs
Hi, here are the recommendations for discussion at next weeks meetings.
There is a new section of RFCs which are ready for discussion but
discussion has been postponed because we're waiting on a key person for
that RFC to be present. This is mostly for RFCs which have been brought up
for discussion in a meeting but, we've postponed. There are a few other
RFCs not on this list where I've ignored them for now because the right
people (mostly Niko) aren't around.
So, there a very few RFCs this week that are obvious candidates for closure
and I we are pretty much up to date in that respect. There is still quite a
backlog of RFCs which we should discuss at meetings and that backlog is
only shrinking slowly. I think in general we don't have enough time at the
general meeting to discuss more RFCs. Should we start discussing RFCs we
might accept at triage? Or are we OK slowly chipping away? Or should we
have another meeting or some other solution?
As usual, if you have comments on any of these RFCs, please add them to the
discussion on the PR; please don't reply to this message.
Cheers, Nick
Proposed for discussion at Rust meeting
---
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/101 - Allow multiple (fixed-size)
subslices borrows in one pattern - krdln
Allows matching several parts of a vec in one pattern. Adds `xs..n`
syntax to match a fixed size slice (and changes variable sized slice
pattern syntax to `xs..` from `..xs`).
Not much feedback - all positive or corrected later to be positive.
Seems like a small generalisation with no downsides.
If we change the syntax as recommended for existing patterns (i.e.,
`..xs` to `xs..`) then the rest should be backwards compatible, I think.
https://github.com/rust-lang/rfcs/pull/113 - Provide a common API across
`Option` and the `Ok` and `Err` variants of `Result` - bjz
Make Option and Result more consistent.
Positive feedback for the idea, some discussion on the specifics.
I believe this was discussed before and we were going to flesh it out a
bit more. Could bjz and aturon update us on progress?
https://github.com/rust-lang/rfcs/pull/116 - Feature gate import shadowing
- Kimundi
Forbid or deprecate name collision of imported names.
Positive feedback.
Recommend: lets do this! Might need to tidy up the RFC, but nothing
major (hopefully). Need to decide whether to depricate via a feature gate
or just get rid. Would be good to assess how much damage this will cause.
https://github.com/rust-lang/rfcs/pull/123 - Rename Share to Threadsafe -
acrichto
Rename share.
Bit of a bikeshed here, some support also for `sync`, `concurrent`, etc.
Recommend: discuss.
https://github.com/rust-lang/rfcs/pull/129 - refine the `asm!` extension -
pczarn
A string/format! based method of doing inline asm.
Not much feedback.
Seems like we could do better with our inline asm, not sure if this is
the right approach.
Recommend: probably close, but worth discussing first.
Proposed for discussion at triage
-
https://github.com/rust-lang/rfcs/pull/150 - fused 'use mod' imports with
relative paths - dobkeratops
Introduces `use mod` to declare and import a module at the same time.
Recommend close - we're pretty happy with this aspect of the module
system and if necessary this could be added backwards compatibly.
https://github.com/rust-lang/rfcs/pull/157 - Use `for` to introduce
universal quantification - glaebhoerl
Use `for` rather than `<...>` syntax for type-parametric items.
Not much feedback, some discussion.
Recommend close - we're not up for changing the syntax of Rust in such
a fundamental way at this stage and want to keep with the
curly-brace-language heritage.
Proposed for discussion at some point
-
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.
Waiting for Niko.
https://github.com/rust-lang/rfcs/pull/22 - Deserializing to a stream of
tagged values - erikt
Changes to the deserialisation framework. Allows for decoding int
