Hi, here are the recommendations for discussion at next weeks meetings. 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/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. https://github.com/rust-lang/rfcs/pull/130 - RFC to remove some special treatment of Box by borrow checker - nmatsakis Make Box a little bit more like a normal struct, but also make it less expressive. Removes the special ability for the borrow checker to distinguish parts of a boxed value. Pretty much no feedback. Probably accept - we want to make Box less special. https://github.com/rust-lang/rfcs/pull/134 - Remove the `'` from lifetime parameters - pcwalton Simplify the syntax of lifetimes by removing the sigil. LOTS of discussion, mix of positive and negative. I think we want to postpone this until we assess the impact of lifetime elision. Should we close this in the meantime or leave it hanging around. Anything to add to it at this point? https://github.com/rust-lang/rfcs/pull/136 - Ban private items in public APIs - glaebhoerl Not much to add to the title. For example using a private struct as a type in a public function. We have a lint for part of this already. Apparently this is used as a hack for some kind of fine-grained privacy for traits. Seems like we should address that properly. Mostly negative feedback, but (I think) only because of the hacks it would break. Lets discuss this. https://github.com/rust-lang/rfcs/pull/143 - FromLiteral - XMPPwocky FromStringLiteral, FromVectorLiteral<T> traits so that types can be constructed from literals. Mixed feedback - mostly (but not all) positive to the idea, multiple problems in the details. I think we will need to do something to make strings and vecs more ergonomic and this is more attractive than ad hoc hardcoding. But it has a lot of problems and may not even be the right approach. Seems like a good start to the discussion, but we should probably think about this in depth. Proposed for discussion at triage --------------------------------- https://github.com/rust-lang/rfcs/pull/170 - Codegen plugins - farcaller Not enough detail to be accepted as an RFC. Propose closing pending more preliminary discussion (which is already happening on discourse). https://github.com/rust-lang/rfcs/pull/154 - Turn capitalization conventions into language rules - glaebhoerl Make our capitalisation warnings into errors. Mostly negative feedback but some positive too. Many problems identified including all the violations in existing code, languages with different capitalisation rules, FFI. Perhaps this should get discussion at a meeting, but I would recommend close. Discussed and postponed for more feedback ----------------------------------------- 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/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. 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) 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? To be closed, more RFCs coming from aturon.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
