Older RFCs for discussion this week

1

Hi, here are the recommendations for discussion at this weeks meetings (sorry I'm running late this week - travel).

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.

Cheers, Nick

Proposed for discussion at Rust meeting

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? Discussed at traige, proposed for possible merge.

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.

https://github.com/rust-lang/rfcs/pull/146 - Scoped attributes for checked arithmetic - glaebhoerl Use an attribute to turn on/off compiler checks for integer overflow. Make integer arithmetic checked by default. Lots of useful discussion around the details of the RFC and some debate over whether the default should be wrapping or checked. Generally positive feedback. We've previously said that we don't want checked arithmetic by default, but perhaps worth discussing if we want something like this.

https://github.com/rust-lang/rfcs/pull/156 - Change extern "ABI" to extern<ABI> or extern ABI or extern(ABI) - glaebhoerl Use an identifier rather than a string to mark the ABI of a function. Just changes the syntax, no actual enumeration of possible values. Some discussion over the exact syntax. Mostly positive feedback. Some negative feedback since the current syntax is similar to C's.

https://github.com/rust-lang/rfcs/pull/159 - Introduce remaining Index traits - sfackler Add IndexGet and IndexSet traits. Change the existing Index and IndexMut traits to take self by value. Some discussion of the details, a little positive positive feedback.

Proposed for discussion at triage

https://github.com/rust-lang/rfcs/pull/193 - Explicit safe interfaces for unsafe code - ecl3ctic Any function which includes an unsafe block must be marked unsafe, unless it is marked with a new #[safe_interface] attribute which denotes unsafe functions which are safe to call. Not popular. Propose close (I suspect this is actually a safer scheme than the current one, but it doesn't seem so much better as to be worth the extra complexity).

Discussion postponed

Actions agreed

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/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/88 - Macro syntax to count sequence repetitions - Eridius pnkfelix + jclements to keep pushing on getting more explanation

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. Agreed to close for now, but to accept a cut down RFC for syntactic changes in order to make such changes backwards compatible if we do them in the future. nrc to coordinate.

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.

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.

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/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. Postponed for discussion at the work week - I can't remember the exact outcome, but we agreed on something and that there would be another RFC...

2

Just want to point out that this is inaccurate: the default was intentionally left unspecified. (Commenters who voiced an opinion were in favor of leaving it unchecked.)

3

Re #184, I thought in the last discourse thread about RFCs up for discussion it was determined that accepted RFCs do not imply being done for 1.0, and therefore if we would accept a patch for an RFC, then that means we should just accept the RFC instead of closing it as postponed.

4

Also, I had requested that RFC #160 (if let) be discussed.

5

Was about to ask about/suggest that too. Glad to see there’s still interest in that.

6

Noted, apologies for getting it wrong.

7

This is just the same text as it was before with no changes. It was discussed at the triage meeting (I believe, I wasn’t there) and it was decided it was worth discussing at the weekly meeting. So, it has just moved section with an extra comment. I’ll mention this when it is discussed.

8

Newer RFCs (or at least those that are requested to be discussed) don’t fall under this category. Any meeting attendee can champion an RFC and add it to the meeting agenda. The purpose of this exercise is so that no RFCs get missed by that system and we only discuss these in the time remaining after higher priority things.

Did you request to me? I don’t recall if you did, sorry. There are (I think) 3 RFCs concerning if let-ish ideas, I thought it best if they were discussed together. If no-one puts them on the agenda this week, they should end up in the ‘older RFCs’ segment next week.

9

Just a heads-up that I’ve updated the checked arithmetic RFC with points from the discussion in the comments. (I don’t think anything substantial was added or changed which wasn’t previously discussed there, so if you’ve read the discussion, there’s probably nothing new.)

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.