[rust-dev] Next week's older RFCs

Nick Cameron lists at ncameron.org
Thu Jul 10 17:48:44 PDT 2014


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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140711/a7046610/attachment.html>


More information about the Rust-dev mailing list