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 into an enum. No commentary for or against. erikt to update? 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. Waiting for Niko. Actions agreed -------------- https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt aturon to comment alex to close https://github.com/rust-lang/rfcs/pull/88 - Macro syntax to count sequence repetitions - Eridius pnkfelix + jclements to keep pushing on getting more explanation https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and blocks huon has updated need more discussion on edge cases - see RFC - pnkfelix (and others)
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
