Update on the "Placement by return" RFC

Two months ago, I published the Placement by return RFC PR, iterating on the work of @notriddle.

The PR still hasn't seen official activity; as far as I can tell, it didn't receive feedback by the lang team and wasn't added to any kind of agenda; nobody is assigned to it.

The discussion on the PR has stopped since a month ago; feedback was given and integrated, and it seems there's a general consensus that the RFC brings something valuable that is worth the added language complexity; and no-one has had anything to add since.

What should happen next? The RFC process doc says:

The sub-team will discuss the RFC pull request, as much as possible in the comment thread of the pull request itself. Offline discussion will be summarized on the pull request comment thread.

But this hasn't happened yet. Now, I don't want to impose, but I would like some assurance that the RFC won't just fall through the cracks. Even having someone from the lang team say "This will be added to the queue and will be processed once we're done with these items which are currently our priority, which will probably take a least X months" would be helpful.

Is there some channel I should go through next? Or should I just wait and be patient?


I'm not on any Rust team but, by following their activity on Zulip and Discord , I'd say that the compiler team, mainly @jschievink, has some ongoing work to improve NRVO. I suppose that means this is a worthwhile strategy, as IIRC, guaranteeing or almost guaranteeing NRVO was the main problem to make it reliable. Anyway, thanks for putting so much work and thought on this!

NB: see the "Status of NRVO-like optimizations" thread on the t-compiler/wg-mir-opt stream on Zulip.


We have a simple NRVO pass on nightly now. I'm working on a more general destination propagation pass that handles those and more cases.

The RFC doesn't seem to require either though.


The RFC doesn't require NRVO, but it's still useful with or without it, and with NRVO it should be very nice to use indeed.

Thanks for the answer, but it feels tangential to what I'm asking.

The way I understand the RFC process, the first steps are to debate whether a given change is desirable, and then publish a semi-frozen spec for that change. Actually implementing the change isn't immediately necessary.

What I'm asking isn't "when will this thing be implemented?", it's "when will this proposal move beyond the status of PR to the status of "official" RFC?". I'm not quite sure how to articulate it, but right now it feels like there isn't any process at all.

Our commnuity has grown substantially since the RFC process was written, but the capacity of the lang team is a bottleneck. It's been clear for a while that the current process is failing in exactly this way: the team is unable to triage RFCs that are not already on the agenda for many months.

In a meeting a few weeks ago, we discussed a modified RFC process that would set expectations better.

How about encouraging people to implement features directly and submit pull requests to the compiler with justification instead of RFCs?

This will naturally reduce the number of proposals to review, since writing code is harder, and also means that at least an initial implementation will already be available rather than the usual pattern in Rust development of waiting for years for someone willing to implement a proposal.

The current RFC process discourages this code-first approach because it gives people the option to just write a proposal instead of coding it themselves, and also because a pull request is not enough, as it may get a "we need an RFC first" answer; this may be one of the causes for Rust's current vast backlog of unimplemented proposals.


That was the process Rust had prior to 2014. The RFC process was implemented to resolve social problems introduced by that policy: most importantly, avoiding large amounts of work being done on features that won't be merged and avoiding accepting features into nightly that may not have a path to stable. We're not going to revert to a process that didn't work at a much smaller scale because the process that worked afterwards has started to fail as well.

While implementation is a blocker, it is not the only blocker, and the initial PR is only a small step on the long path toward stabilization. The new process we want to move toward requires RFCs to have champions of some kind as the first step of moving toward implementation, to help check that accepted proposals will have forward progress made on them.


So if I'm understanding you correctly, it's "wait and be patient" for now?

Niko has posted the RFC describing the proposed new process: https://github.com/rust-lang/rfcs/pull/2936

1 Like