Micro Pre-RFC: todo! macro

libs
41

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.

1 Like
42

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

43

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")

44

Let's not overcomplicate it:

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

2 Likes
45

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: image

Which is even less typing than todo!.

46

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

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

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)?.

48

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 :wink: this is worse than ?

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

49

@RustyYato

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)?)?)?
50

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

1 Like
51

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

52

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