Micro Pre-RFC: todo! macro


#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.


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


#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

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

#50

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


#51

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


closed #52

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