diff options
| author | Mazdak Farrokhzad <twingoow@gmail.com> | 2019-03-19 15:16:43 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-03-19 15:16:43 +0100 |
| commit | d4dd8604eb76683e1bb613cc35d3ad970f4d372f (patch) | |
| tree | 95a2b55faa646337fd6ad3bb901c0112aa5f3fed /src/libstd/lib.rs | |
| parent | ef4d1c419525e1510aa650e2bec0d8f7449a2130 (diff) | |
| parent | 9d408d972f7cf16162ec3ab35e11c659ccee9566 (diff) | |
| download | rust-d4dd8604eb76683e1bb613cc35d3ad970f4d372f.tar.gz rust-d4dd8604eb76683e1bb613cc35d3ad970f4d372f.zip | |
Rollup merge of #56348 - matklad:todo-macro, r=withoutboats
Add todo!() macro The primary use-case of `todo!()` macro is to be a much easier to type alternative to `unimplemented!()` macro. EDIT: hide unpopular proposal about re-purposing unimplemented <details> However, instead of just replacing `unimplemented!()`, it gives it a more nuanced meaning: a thing which is intentionally left unimplemented and which should not be called at runtime. Usually, you'd like to prevent such cases statically, but sometimes you, for example, have to implement a trait only some methods of which are applicable. There are examples in the wild of code doing this thing, and in this case, the current message of `unimplemented`, "not *yet* implemented" is slightly misleading. With the addition of TODO, you have three nuanced choices for a `!`-returning macro (in addition to a good-old panic we all love): * todo!() * unreachable!() * unimplemented!() Here's a rough guideline what each one means: - `todo`: use it during development, as a "hole" or placeholder. It might be a good idea to add a pre-commit hook which checks that `todo` is not accidentally committed. - `unreachable!()`: use it when your code can statically guarantee that some situation can not happen. If you use a library and hit `unreachable!()` in the library's code, it's definitely a bug in the library. It's OK to have `unreachable!()` in the code base, although, if possible, it's better to replace it with compiler-verified exhaustive checks. - `unimplemented!()`: use it when the type checker forces you to handle some situation, but there's a contract that a callee must not actually call the code. If you use a library and hit `unimplemented!()`, it's probably a bug in your code, though it *could* be a bug in the library (or library docs) as well. It is ok-ish to see an `unimplemented!()` in real code, but it usually signifies a clunky, eyebrow-rising API. </details>
Diffstat (limited to 'src/libstd/lib.rs')
| -rw-r--r-- | src/libstd/lib.rs | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/src/libstd/lib.rs b/src/libstd/lib.rs index fc8ac9a0b3e..296c4c88727 100644 --- a/src/libstd/lib.rs +++ b/src/libstd/lib.rs @@ -301,6 +301,7 @@ #![feature(stmt_expr_attributes)] #![feature(str_internals)] #![feature(thread_local)] +#![feature(todo_macro)] #![feature(toowned_clone_into)] #![feature(try_reserve)] #![feature(unboxed_closures)] @@ -323,7 +324,7 @@ use prelude::v1::*; #[stable(feature = "rust1", since = "1.0.0")] pub use core::{assert_eq, assert_ne, debug_assert, debug_assert_eq, debug_assert_ne}; #[stable(feature = "rust1", since = "1.0.0")] -pub use core::{unreachable, unimplemented, write, writeln, r#try}; +pub use core::{unreachable, unimplemented, write, writeln, r#try, todo}; #[allow(unused_imports)] // macros from `alloc` are not used on all platforms #[macro_use] |
