Next week's older RFCs for discussion

1

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.

Cheers, Nick

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 :slight_smile:     Mixed feedback.     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 :slight_smile: 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 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.

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

2

Regarding https://github.com/rust-lang/rfcs/pull/184 (tuple indexing), if this is something that we’d accept a patch for, but that the core team would not do themselves for 1.0, is “close as postponed” really the right approach? My belief is “close as postponed” means “we’re not doing this now, but we’re open to discussing it again in the future”. That’s different than “we like this, it’s low-priority so we won’t do it for 1.0, but we would accept community patches that implement it”.

Given that, can we not just have a way to accept an RFC as low-priority? There seems to be an assumption right now that accepted RFCs are expected to be implemented for 1.0, but that doesn’t actually have to be the case.

3

@lilyball according to the README it's already as you suggest:

Furthermore, the fact that a given RFC has been accepted and is 'active' implies nothing about what priority is assigned to its implementation, nor does it imply anything about whether a Rust developer has been assigned the task of implementing the feature.

...

Some RFC pull requests are tagged with the 'postponed' label when they are closed (as part of the rejection process). An RFC closed with “postponed” is marked as such because we want neither to think about evaluating the proposal nor about implementing the described feature until after the next major release, and we believe that we can afford to wait until then to do so.

(In other words an accepted RFC means "we'd like to do this", without any implicit judgment as to when, while postponed means "we don't even want to think about it right now".)

4

In that case, I see no reason at all to “close as postponed” an RFC that we’d be willing to accept a patch for. If we will accept a patch, then that means the RFC as-is should be accepted.

5

It could be that further consideration of the RFC depends on seeing a prototypical patch.

6

Perhaps it was not clear, but what I meant was that we should discuss whether we should close it as postponed or whether it is something we would accept a patch for. If we would accept a patch, we should probably accept the RFC. I hesitate to say ‘should always’ since there is going to be a spectrum of desirability and I can imagine a situation where we would take a patch if it were provided and perfect, but we wanted to strongly discourage people from working on it.

7

Ah hah, that makes more sense. I hope it gets accepted :).

I can see what you’re saying about “we would accept a patch for this, but we do not encourage anyone to create such a patch unless they personally need it”, but I’m not sure offhand what sort of RFC would actually warrant such a response. So we can probably avoid thinking about that edge case unless it actually comes up.

8

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.

There is more comments in the pull request since the beginning of this thread.

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.

9

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