[rust-dev] Older RFCs up for discussion next week

Nick Cameron lists at ncameron.org
Thu Jul 3 19:20:03 PDT 2014

Here are the recommendations for discussion at next weeks meeting. Last
week we didn't have time to cover older RFCs at the general meeting, so
last weeks RFCs are carried over. Also added is RFC 88 for an update. It
was previously discussed and we decided it hadn't reached a conclusion.

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/88 - Macro syntax to count sequence
repetitions - Eridius
    pnkfelix - have we reached a conclusion here?

https://github.com/rust-lang/rfcs/pull/16 - attributes on statements and
    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
    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
    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 -
    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
    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/124 - cloned and stable - tommit
    allows C++-like implicit move-optimizations. `cloned` on an arg forces
a pass-by-clone semantics, `stable` before an arg allow implementors to
choose the passing semantics per implementation.
    Negative feedback. Possibly impractical due to an implementation issue.
    Propose close - too much complexity and uncertainty for unknown benefit.

https://github.com/rust-lang/rfcs/pull/125 - prefetch intrinsics - saati
    Data showed no benefit and the proposer thought we should not implement
after all. Question about whether we might want this on other platforms
    Recommend close (maybe as postponed) - I expect we will find a proper
use case for this at some point, but would be backwards compatible to add

https://github.com/rust-lang/rfcs/pull/126 - add optional type parameter to
`include_bin!` - tommit
    Not really sure what is going on here, sorry. huon seems to know.
    No positive feedback and it is unsafe.
    Recommend close.

https://github.com/rust-lang/rfcs/pull/128 - Rename mod.rs files to self.rs
- tommit
    Just what it says in the title :-)
    Mixed feedback, but mostly negative.
    Recommend close.

https://github.com/rust-lang/rfcs/pull/137 - Objects of type T should be
implicitely convertible to &T - Tomaka17
    Auto-borrow types in argument position as well as self position.
    Mixed feedback. zwarich points out a problematic interaction with copy
    Recommend close.

https://github.com/rust-lang/rfcs/pull/152 and
https://github.com/rust-lang/rfcs/pull/153 - function overloading of
different kinds - iopq
    Recommend close as postponed.

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

More information about the Rust-dev mailing list