Micro Pre-RFC: todo! macro

[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!.

[Tom-Phinney]

Those of us whose ToDo lists are not bugs might instead choose

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

[arthrowpod]

If we do end up adding typed holes and use ? for them, we’d need to resolve a syntactic ambiguity: return ? could be parsed as return (?) or (return)?.

[Yato]

We can’t use ? because it can be used as the try operator, and that would be confusing.

note, the Try trait is unstable, but the try operator, ?, is stable.

https://doc.rust-lang.org/1.28.0/std/ops/trait.Try.html

We could use ?? though. More symbols, less problems this is worse than ?

---

this is off topic, @arthrowpod, if you want to continue discussion on type holes, then please create a new thread.

[arthrowpod]

@Yato

Type holes are precisely this thread’s topic.

Also, using ?? creates an even worse parsing problem. return ??? could mean any of the following things:

return ((??)?)
(return (??))?
(((return)?)?)?

[Riateche]

We could use ?? though. More symbols, less problems

This would be just as confusing as ? is, because ?? is currently valid and means applying the try operator twice.

[Yato]

Could we reuse the _ syntax for type holes, they already mean “let the compiler figure this out”

[system]

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