This week's older RFCs up for discussion


#1

Hi, here are the recommendations for discussion at next weeks meetings. Apologies for the lateness this week, I’ve been travelling a lot. Next week’s should be at the usual time.

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

https://github.com/rust-lang/rfcs/pull/132 - UFCS - nmatsakis     Universal function call syntax. Use ::Foo syntax for specifying the trait as well as the concrete type for a function call.     Previously discussed as an older RFC.

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.

https://github.com/rust-lang/rfcs/pull/147 - allow empty structs with braces - mahkoh     Allow struct Foo {} as well as or instead of struct Foo;. Also initialisation/destructuring. Question about whether we should also allow ().     Lots of love, lots of hate.     Need to iron out the details, but I think we can make a quick decision about the principle.

Proposed for discussion at triage

https://github.com/rust-lang/rfcs/pull/143 - FromLiteral - XMPPwocky     Trait for creating objects from string/vec/numeric literals.     Lots of support for the general idea, but also lots of discussion on how specifically to do it. No conclusions.     Propose closing - needs a new RFC (or at least new version of the RFC) that takes into account all the comments. We might want to offer guidance on whether this is pre- or post-1.0, I suspect the latter.

Discussed and postponed for more feedback

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.     If we change the syntax as recommended for existing patterns (i.e., ..xs to 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.

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

Proposed for discussion at some point

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?

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/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 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/123 - Rename Share to Threadsafe - acrichto     Rename share.     Bit of a bikeshed here, some support also for sync, concurrent, etc.     nmatsakis to merge


#2

Could I suggest https://github.com/rust-lang/rfcs/pull/179 “Change the &mut T pattern to &mut.” too? (It’s a fairly small thing and discussion has died down.)


#3

If you have an RFC that a core team member (such as yourself) wants to champion, I’d say put it on the Tuesday mtg agenda, instead of making @nrc have to update this laundry list.

But that’s just my suggestion; maybe @nrc would prefer to actually keep things unified on his list.


#4

Yeah, pnkfelix is right. Urgent RFCs should be added to the agenda. This list is meant to be just a sweep of older ones so nothing gets forgotten. In fact I specifically avoid any RFCs which have had any (well, approximately any) discussion in the last week or so.