What about adding `stub!` macro to the `std`?

Currently, we have to write like this:

fn foo() -> i32 {
    // TODO: need to implement

It would be convenient to have a special macro to make stubs like todo! or dbg!:

fn foo() -> i32 {
    stub!()  // for default value

fn bar() -> bool {

let bazz = stub!(bar());
[src/main.rs:2] stub: 0
[src/main.rs:6] stub: true
[src/main.rs:11] stub: bar() = true

Additionally, it can be added compiler warnings. What do you think?

So... this is like unimplemented!()/todo!(), but instead of panicking it just produces Default::default()? Aside from obviously not working when there's no Default impl, I don't see why that would be any more useful than actually writing Default::default() or whatever the intended stub implementation is yourself; if you don't have an intended stub implementation yet then that's just what todo!() is for.


It's a nice to have, but // TODO works well enough. You can use dbg!(true) // TODO if you prefer something noisy.

Personally, I find it rare to be able to replace method with a fixed value and have the program run. I either can use todo!() for unused functions, or I just write a bad implementation that's usually still more than a default value or a single expression.

No. This produces Default::default() only for calls without argument expression. In addition, this will print the value to stdout and produce compile warnings.

So now it assumes the type implements Debug or Display, too?

I personally think this is too much for std. That said, I do think it might be nice if a warn! macro were added to std that would emit a warning when the macro is expanded. Sort of like compiler_error!, but not fatal. That way you could implement stub! all by yourself and have it emit a custom warning.


Hmm.. it’s better not to do that. In principle, the stdout messages are of little use, compiler warnings are enough.

Adding the warn! macro is a good idea. However, I would like to see in the std a complete set of tools that simplify development (such as todo! and dbg!). The requirement to use an external crate greatly complicates the quick start.

But Rust is a language that, by design and intent, has a minimal std. The functions you want are also needed in no_std crates. Thus inclusion in std, which contains mostly things that need compiler support, seems inappropriate.