Every RFC is blocked on labor hours, this is why they all only occasionally make progress.
The rest of this post is 100% my personal opinion, which I have not consulted anyone else about.
I think that the best thing to do to advance that RFC is to reduce its scope dramatically. Rust grows incrementally. Even if we assume that this RFC has no “unknown unknowns” about how it interacts with the rest of the language, I personally can’t begin to evaluate if everything proposed by that RFC is actually advantageous to Rust.
This is what seems to me like a reasonable path toward the features this RFC proposes:
- The community reaches consensus that some form of const parameters is useful and needed enough to be prioritized right now.
- We start small with something like parameterization by
usize, generalizing arrays, with consideration toward how it will be extended in the future.
- Probably from that point we would consider generalizing to parameterization by arbitrary const values of different types.
- Once we have that, I think we could consider adding const expression bounding clauses of some kinds (though possibly not all at once, either).
I think the way we’ve been handling higher-kinded polymorphism (which has been making a lot of progress toward consensus) serves as an instructive contrast. I started with an RFC proposing what seemed like the most clear step toward “higher kinded types,” but it was decidedly an incremental step and not the entire feature. As we’ve considered the proposal and its potential extensions, that RFC has been scoped back even further, limitations I didn’t initially know were necessary have been added to it, and we have a sort of long term action plan (including unresolved questions and trade offs) figured out.
There are also questions about how this fits into the roadmap for 2017, and what the real motivation is for this feature. My impression is that scientific computing is the most practical motivation for const parameters, and I’d like to hear more about what use cases like that need. Dependently typed proofs of correctness are not in themselves a convincing motivation to my mind, but most of what I’ve seen in this space in Rust has been focused on that sort of thing.
Lastly, I think this RFC is to a certain extent blocked, implementation wise, on const fns and associated consts, two features in the same space which exist but remain unfinished for various reasons (those reasons are outside of my domain so I can’t comment on what they are).
All of this is not to say that the work that has gone into this RFC has not been useful toward its end goal. Even though I have a hard time imagining this RFC being accepted in one step, it has laid the groundwork for a series of RFCs to potentially build toward its end.
So tl;dr: I think this RFC would make progress more quickly with a reduced scope and clearer motivations. (This probably applies to all RFCs!)