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; they are more likely to be seen and remembered there.
Proposed for discussion at Rust meeting
This week I would like to come back to the RFCs we have previously discussed, but punted on. See below. Perhaps we should pick champions or something to ensure we have someone for each RFC with good enough knowledge to get the RFC accepted or closed at the meeting.
And if we have time:
https://github.com/rust-lang/rfcs/pull/145 - Memory exploit mitigation - kmc Add attributes and compiler flags for hardening against memory exploitation. E.g., aslr, stack canaries. Not a lot of feedback for or against (some bikeshedding over how exactly to specify the level of hardening to the compiler). Recommend discuss.
Proposed for discussion at triage
https://github.com/rust-lang/rfcs/pull/161 - int/uint portability to 16-bit CPUs - 1fish2 Change int/uint to be at least 32bit or rename to index/uindex. Recommend close (after discussion), changes to int/uint have been discussed and rejected before. No new motivation here.
https://github.com/rust-lang/rfcs/pull/167 - Allow multiple crates in one
extern crate declaration - liigo
Just what the title says
Recommend close as postponed - might want this sugar one day but it is ultra-low priority and backwards compatible.
https://github.com/rust-lang/rfcs/pull/182 - Make accessing Unsafe fields unsafe - arielb1 Another nice and descriptive title A different approach to unsafe fields. Some discussion of the relative merits vs unsafe fields, no other feedback. Recommend close - we’ve discussed and postponed unsafe fields before.
https://github.com/rust-lang/rfcs/pull/184 - Tuple indexing - P1start Allow indexing tuples to extract their fields without destructuring. Mostly positive feedback. Recommend close as postponed - I would personally like to do this and it seems popular, but it is also backwards compatible and low priority, so we shouldn’t do it pre-1.0. Maybe we would take a patch for this though?
https://github.com/rust-lang/rfcs/pull/191 - Currying - iopq Implicit currying of functions and closures. Recommend close - not a 1.0 thing for sure. Maybe not a Rust thing at all.
Discussed and postponed for more feedback (for discussion next week)
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
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..) 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.
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/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.
nmatsakis to take some measurements and report back
https://github.com/rust-lang/rfcs/pull/17 - Iterable trait family - erikt aturon to comment acrichto 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/113 - Provide a common API across
Option and the
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.
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. Implementation in progress, RFC to be updated soon-ish.
https://github.com/rust-lang/rfcs/pull/135 - where clauses - nmatsakis Allow specifying bounds on type parameters in a where clause as well as inline. This is more expressive and neater in the presence of many type parameters or bounds. Mostly positive feedback. Some worries around having inline bounds and where clauses. Some worries about the ‘multiple dispatch’ part of the proposal. Update (Niko) and to be merged
https://github.com/rust-lang/rfcs/pull/155 - require
impl MyStruct to be nearby the definition of
MyStruct - apoelstra
Require impls without traits to be in the same module as the types they are impls for. Solves a problem with ‘invisiible’ static methods. But prevents a (perhaps) useful pattern of dependency injection-style adding behaviour externally.
pcwalton to merge
https://github.com/rust-lang/rfcs/pull/127 - Opt-in builtin traits, take 2: default and negative impls - nmatsakis Unsafe (trusted) traits (see also 117, now closed) which express an invariant to the compiler and default impls - which must be opted out of, rather than in. Niko to update with 1.0 path.