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

language design
1

Currently, we have to write like this:

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

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 {
    stub!(true)
}

foo();
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?

2

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.

8 Likes
3

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.

4

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

5

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.

7 Likes
6

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.

7

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.

3 Likes
8

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