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.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.