Micro Pre-RFC: todo! macro

[cuviper]

A macro expanded inline will directly give you relevant line information when it panics. With a function, you’d have to use RUST_BACKTRACE=1 and hope the optimizer didn’t obfuscate it too much.

[matklad]

Another benefit of the macro is that you can pass an optional message: todo!(“issue #92”)

[TimDiekmann]

You could even format the message like todo!("{}", 42)

[Yato]

This shouldn’t be necessary, since this should just guve a message about what to do, instead of putting it in a comment. But since this is a macro I suppose there is no harm in doing it.

[TimDiekmann]

At least for macro impls it’s pretty useful and we’ll find more scenario, too I guess.

[bjz]

Yes! Would love typed holes, especially if you can name them, then give a list of out-standing things todo, along with relevant bindings. And then editor commands associated with those holes. It’s a more involved proposal though - we should get an RFC up for it - I’ve really missed them in Rust! It would increase the pressure on the LSP to add hole-related stuff (this is currently quite lacking, sadly).

[pftbest]

Why does unimplemented! need to be deprecated? Seems like unnecessary friction. I think there are valid use cases for it that would look awkward when replaced with todo!.

[birkenfeld]

You can replace with panic!("something about unimplemented") instead. It’s also clearer to the casual reader.

[Nashenas88]

I’ve been playing around with Idris recently and thought holes could be a great addition to Rust. There’s been so many instances where I’ve just wanted to ask, “What is the type here?” Sometimes trying to force the compiler to give me a name with the unit type feels really cumbersome.

[dpc]

when you want to type code fast.

makes it harder to type.

I would like to advise people to configure RLS and autocompletion in their code editors. I don’t think typing speed is an important argument. And uni<tab> works well for me.

I like the idea (looks better, sounds better, carried the intention well), but maybe it could be implemented as a standalone crate first.

We could just use todo::todo and we don’t have to worry about breaking changes, and we can iterate over the idea.

[Centril]

but maybe it could be implemented as a standalone crate first.

Honestly, this feels like a standard answer… There’s no chance on earth that I’d pull in a todo crate when unimplemented! is so close by… it’s similar to how we introduced dbg! to libstd because the convenience of having it in libstd is the whole point.

[dpc]

There’s no chance on earth that I’d pull in a todo crate when unimplemented! is so close by

What’s the point of “fixing it” then, if people wouldn’t even bother to make a slightest effort. With Rust 2018, adding a crate is like :!cargo add todo (Vim command syntax), and then you can just use todo::todo;.

I created even simpler crate, and I am actually using it all the time now. : https://crates.io/crates/default

[Centril]

What’s the point of “fixing it” then, if people wouldn’t even bother to make a slightest effort.

The whole point of todo! is to lessen the effort; If the effort is more for cargo add todo + todo::todo! then I’ll stick to unimplemented!() as the more convenient solution.

[Soni]

But unimplemented has the “wrong” (read: different from todo) semantics. Your code is bad because you use unimplemented where you should be using todo.

An example: if you’re making something that turns pulseaudio API into an ALSA client, things like get_daemon_pid should be unimplemented! but other things should probably be just todo!

[Centril]

But unimplemented has the “wrong” (read: different from todo) semantics.

Sure; this is all true… however, when I’m typing unimplemented!() I’m not really thinking about this as a permanent thing because it will be gone in the next hour or so… in nearly all cases it is just for prototyping. Thus, the naming isn’t all that important… the ergonomics and is-this-the-thing-I-intuitively-reach-for-name matters.

[Tom-Phinney]

But for many coders, including me, some things remain unimplemented!() for months or years, and in those cases it would be useful to know whether they are placeholders/hooks for unexplored alternatives – real unimplemented – or simply things that are intended but not yet accomplished – real todo items. Labeling everything unimplemented!() conflates that difference.

[Centril]

Labeling everything unimplemented!() conflates that difference.

I agree! deconflating seems to me an added benefit atop of the improved ergonomics.

[TimDiekmann]

It might be practical to keep unimplemented next to todo. With the former, there will always be a warning as a reminder: “You have to do this” and is likely to exist only for a short time in the source code. It also suggests converting it to todo, which is suitable for long-term use.

Also, it would be cool to have the option to specify an issue number:

todo!(#13, "short description")

[josh]

Also, it would be cool to have the option to specify an issue number:

Let’s not overcomplicate it:

todo!("#13: short description");

[scottmcm]

I still feel like

panic!("BUG#13: short description");

Is just fine for that, since it’ll be found by the same tooling that finds // BUG#13 comments in code…

And if you want to type less, use any editor with templates. For example, sublime does this:

Which is even less typing than todo!.