Using the todo macro to typecheck unwritten code that will be implemented in the future
We'll replace the println! macro with a call to todo!, which has
the additional benefit of type-checking so we won't need to finish
anything with todo! in the expression. Note that if we call a function
with todo!, we do get the panic! behavior.
We do have two other options for achieving the same thing,
unimplemented! and panic!. All three of these options functionally
do the same thing: they crash the program immediately.
We aren't using panic! because panic! should be used when a program
reaches an unrecoverable state. We don't have an unrecoverable state
so much as a piece of the program we intend to work on later.
For similar reasons, we aren't using unimplemented! because we want
to convey that this is something to work on while unimplemented!
doesn't necessarily mean that we intend to work on it.
Instructor: [0:00] Our main function uses the PrintLlne macro which prints out "Hello World" when we run it. We're going to replace the PrintLine macro with a todo Macro. Now, when we run our application, we'll see that the thread panics. It panics with a specific message, "Not yet implemented."
[0:17] Todo has a very specific benefit over PrintLine in that it will allow us to type check our program without actually completing the implementation. How it does that is out of scope for this lesson, but we do have two other options that we could have used instead, as well.
[0:32] The todo macro itself indicates unfinished code as specified in the documentation. This can be exceptionally useful if you're prototyping, or trying to type check the code without actually implementing the implementation. Unimplemented and panic are two macros that do the same thing as todo. All three of these macros will panic and crash the application.
[0:55] The reason we aren't using panic here is because panic should be used when a program reaches an unrecoverable state. What we have here is not an unrecoverable state, so much as an intent to implement future functionality.
[1:08] For similar reasons, we aren't using unimplemented. Unimplemented just says, "We haven't implemented that code." Whereas using todo indicates some intent to implement that in the future, unimplemented carries no such connotations.
[1:24] That said, if you feel like panic or unimplemented is better for your use case, feel free to use them.