This week's older RFCs

Hi, here are the recommendations for discussion at this 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.

Cheers, Nick

Proposed for discussion at Rust meeting

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. 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.

https://github.com/rust-lang/rfcs/pull/163 - Add a matches!(expression, pattern) macro - SimonSapin Add a macro which returns a bool, true if the expression matches the pattern. This is similar, but complementary to if let. It does not bind any variables like if let does, but it can be used anywhere a bool could be used, not just to replace an if statement. E.g., you could write if foo && bar && matches!(...) .... RFC because it adds a macro the prelude. Very positive feedback. Some bikeshedding over matches! vs is_match! vs an is keyword.

https://github.com/rust-lang/rfcs/pull/164 - Feature gate some slice patterns - brson Add an advanced_slice_patterns feature gate to forbid use of slice patterns in head or middle position. Some discussion on whether or not it is a good idea, no conclusions.

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).

https://github.com/rust-lang/rfcs/pull/203 - Combine trait for string and collection concatenation - apoelstra Replace concatenation operator (+) with ++, implemented via a Combine trait. Because + for strings and vecs is not commutative. Implement Combine for all collections. Some support in the comments. This might merit discussion in the weekly meeting, but I thought we could run it through triage first. My thoughts are that we might want to reconsider how we handle concatenation, and this might be a good starting point, but then again, maybe not (it seems to me at least that the motivation presented is motivation for 'Haskell with pointers', not for Rust).

https://github.com/rust-lang/rfcs/pull/211 - Extended Try - TyOverby Add an argument to try! which is a constructor for the error kind. Not much feedback Recommend close with a recommendation to implement this as a different macro (it does seem like a good idea, just not to replace try!).

https://github.com/rust-lang/rfcs/pull/215 - allow macros in all ident positions - manishearth Allow macro uses everywhere an ident is allowed Not much feeback, but not positive. Recommend close as postponed. We probably want more felxible macros in this respect at some point, but priority for 1.0 ought to be getting confidence in the existing set.

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...

https://github.com/rust-lang/rfcs/pull/184 - Tuple indexing - P1start Allow indexing tuples to extract their fields without destructuring. Mostly positive feedback. Accept without the float syntax and behind a feature gate, brson to merge

Related issues: Encourage fixed-size integer · Issue #16446 · rust-lang/rust · GitHub

The main problem is that people are used to use int or uint for everything and the documentation may not be enough (cf. Guide: what to do about int · Issue #15526 · rust-lang/rust · GitHub) to stop this bad and dangerous habit:

The index or intptr are more meaningful than the simple int which, for many languages, do not denote any memory-related notion.

I think renaming int and uint worth the backwards compatibility break because it will be the (only) occasion to check for good int or uint use in existing code before they create more issues…

I have attempted to start a conversation about this on a separate thread, namely here: http://discuss.rust-lang.org/t/if-int-has-the-wrong-size/454

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