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

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