For me the most anticipated feature in all of the rust ecosystem is RFC #1657: const-dependent type system. However the discussion on it hasn’t moved for 3 months. It isn’t blocked on anything.
What should be done in such cases? Who is responsible for pushing the discussions on RFCs? Is this the shepherd’s role? And what can an outside observer do if he wants to push such RFC, where there are no clear issues but also no progress?
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:
usize, generalizing arrays, with consideration toward how it will be extended in the future.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!)
To some extent, you are. If you are interested in an RfC, you should try and drive the conversation. Attempt to ignite discussion of the issues that have been brought up. Attempt to get more eyes on it (this post of yours is one way of doing it). The shepherds will help it move through the later stages, but there's no compulsion to push on stagnant rfcs -- an rfc should demonstrate sufficient interest. So while the shepherds will try to keep things moving, in general try to push for comment on rfcs when this happens.
Also worth mentioning that the lang team has recently been trying to resolve RFCs that haven’t seen recent activity to clear up the ‘backlog’ (there are ~30 lang RFCs outstanding right now) but I know when I was doing a pass I focused on merging/closing small RFCs that hadn’t received recent comments, because its much easier to move forward on those than something very significant like this one.
@eddyb can probably comment on this. He seems to be the one doing the work on cleaning up/refactoring the compiler (see his series of patches) to allow a working implementation of associated consts and const fns, and maybe even allow integrating miri at some point.
This has to happen before somebody can even start prototyping a toy implementation of any highly reduced form of type level const values, like just type level usize to abstract over arrays, since "basic stuff" (ok, this is not so basic :D) like
trait A {
const N: usize;
fn foo() -> [T; Self::N];
}
does not work yet.
So it seems to me that the biggest blocker currently is rustc itself. Smaller RFC would be easier to write if the things being proposed could actually be implemented in a reasonable time-frame.
However, it doesn't look like integrating miri into rustc is a priority, but prioritizing it would be a huge enabler for the 2017 roadmap. Miri would not only be good for type-level integers, but it could enable MIR-based optimizations that generate better code, and can reduce compile-times (if we are able to use them to feed less IR to LLVM). They also would be good for tooling. An IDE that can tell you that a branch will never be taken because some value will always be a constant is very useful (clang and gcc already emit these kinds of warnings, but clang static's analyzer does way more).
What do you think should be deprioritized to raise the priority of this work?
I did not meant to suggest that we should de-prioritize something in the Roadmap to "just add type level const to the language", but rather raise awareness that lying the foundation for any work in this area to happen might already be on the 2017 Roadmap (we would just need to acknowledge it and make it a more concrete task with a well defined scope).
Four of the main goals mentioned in the 2017 Roadmap RFC are:
improving compiler performance: miri integration could enable better MIR optimizations, reducing the amount of LLVM IR generated. Since in some cases ~50% of the compilation phase is spent in LLVM, anything that reduces the amount of LLVM IR generated might speed up the compiler.
better error messages: out-of-bounds access of arrays, dead code (branches that will never be taken), tautological / unnecessary comparisons, floating-point expression reordering... miri integration could enable these being implemented in clippy or even compiler.
solid but basic IDE support: better error messages would improve the IDE experience, but miri could also enable more advanced IDE features with more static analysis. It might be worth it to explore at least one feature (e.g. dead code elimination) that could heavily rely on miri to ensure that these can be accommodated by the language server (I don't see any reason why this shouldn't be the case though, so this argument doesn't have much weight).
improving Rust usability: not being able to easily abstract over arrays of different sizes is an annoyance that C++ does not have. New users clash every now and then against it, and the suggested workarounds give a bad first impression of rust. This annoyance becomes a larger usability problem in heavily math-based applications, low-level applications that require SIMD, ... Miri integration would enable prototyping a "minimal type-level usize" RFC (not necessarily in 2017) to improve this aspect of Rust.
Maybe in isolation none of these goals would justify trying to get miri integrated into rustc in 2017, but I think that all of them combined make a good case to at least acknowledge that working on this "task" is important. I see miri as an "enabler" piece of technology for all of the above and more (like fixing the ton of const fn and associated consts bugs currently preventing their stabilization, prototyping type-level integers/consts...). And in my opinion is something that should be integrated into the compiler sooner rather than later.
Should this delay work on incremental compilation, ATCs, specialization / lattice rule, virtual structs, the rust language server, non-lexical lifetimes, ... ? Obviously not, but "integrating miri into rustc" should be up in the list right next to all of these.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.