I totally share the pain, but I think making it easy to write unimplemented!() is something the editor should help us with.
(I like Python’s pass. It doesn’t do anything, but it’s very nice to use to just stub out things, even if you’re going to write them say the next hour. That’s how I use unimplemented!() in Rust too.)
Smart editors do help (omg, I do remember my excitement when IntelliJ get enough macro support to autocomplete unimplemented), but they are not always available: I use playground, I sometimes use unconfigured vim, etc.
However, I don’t see any downsides in having todo, so, if this can be achieved without editor support. Kotlin is a fun example here: it could have all kinds of editor support here, but it just has a TODO function.
Does it need to be a macro? How about a function:
fn todo() -> ! {
panic!("not yet implemented")
}
I feel that wrt. auto-completion todo! is imo better because it fits the intent so it’s easier to remember and auto-complete to.
Is there a drawback to a macro?
The upside is that you can make it potentially work in type, pattern, and bounds contexts as well later if need be if it is a macro.
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.
Another benefit of the macro is that you can pass an optional message: todo!(“issue #92”)
You could even format the message like todo!("{}", 42)
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.
At least for macro impls it’s pretty useful and we’ll find more scenario, too I guess.
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).
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!.
You can replace with panic!("something about unimplemented") instead. It’s also clearer to the casual reader.
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.
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.
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.
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. : crates.io: Rust Package Registry
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.
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!
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.