Description
Proposal: add compile-time checked version of unimplemented!()
We all know and love the unimplemented!() macro for keeping track of things we haven't yet gotten around to. However, it is only checked at runtime if a certain code path is encountered. This is fine in many cases, but when writing new code from scratch (especially when porting), refactoring large amounts of code, or building comprehensive new features, you often have segments of code that you haven't implemented yet, but you know you'll have to.
At least for me, it is common to write a chunk of code, but leaving out some annoying edge cases, or maybe logic (like generating a unique identifier) that I want to deal with alter. I know that I will have to complete that block of code before the program does something useful, but I want to do it later. This can be either because I want to complete the main logical flow of the code first, because I haven't figured out how to do that part yet, or simply because I want to see if the rest of my code compiles correctly.
It would be extremely useful to have a variant of unimplemented!() that would generate a compile-time error if present in my code. Something like incomplete!(). However, it should have some properties that I believe mean it can't be implemented without some help from the compiler:
- It should be usable as an expression of any type (similar to
!forunimplemented!()) - It should only error if the program compiles correctly. Or rather, it should not prevent any other errors from being printed. In essence, all passes of the compiler (including the borrow checker) should run despite the presence of
incomplete!(). - It should not emit warnings about dead code or unused variables following it (which using
unimplemented!()does).
The closest I've been able to come up with on my own is the following
macro_rules! incomplete {
() => {{
#[deny(non_snake_case)]
let _mustBeImplemented = ();
loop {}
}}
}This will only error out after all compiler passes (2), and since it returns !, it is sort of usable in place of any expression (1). However, it does not fit (3), because the infinite loop makes the compiler believe that all code following it is dead. Furthermore, the error it produces is obviously not appropriate for what the macro's intent is.