Crates.io | todo_by |
lib.rs | todo_by |
version | 0.3.0 |
source | src |
created_at | 2023-05-13 08:33:11.873569 |
updated_at | 2023-05-18 14:31:32.348448 |
description | Compile-time lifetimes for comments. |
homepage | https://github.com/parker-codes/todo_by/ |
repository | https://github.com/parker-codes/todo_by/ |
max_upload_size | |
id | 863622 |
size | 12,776 |
Compile-time lifetimes for comments.
To use this macro, add it to your dependencies via Cargo:
cargo add todo_by
Then, import and invoke the macro and add a date (such as above a function or statement) like so:
use todo_by::todo_by;
todo_by!("2023-06-01");
fn my_function() {
// TODO: Implement this function by June 1st, 2023
}
If the current date is after June 1st, 2023, the macro will generate a compile error with the message “TODO by Jun 1, 2023 has passed”. If the current date is on or before June 1st, 2023, the macro will expand to nothing and the code will compile normally.
You can also add specific TODO comments:
todo_by!("2023-06-01", "Clean up implementation");
The todo_while
macro allows you to ensure todos are done based on a semver requirement of what is in your Cargo.toml:
use todo_by::todo_while;
todo_while!("<1.0.0", "This has to be in the first major release")
This also allows you to make blockers:
todo_while!(">123.4", "Must fix this or bump the version")
Currently, if you publish/offer a crate and a todo_by expires in the lib code, then it would be an unfixable compilation error for anyone importing the crate. This problem is being investigated - please offer solutions if you have any!
Here're some alternative implementations for other languages and tools: