#options #no-std-compatible #auto-unwrap #implicitly-unwrapped

no-std dangerous_option

This crate provides DangerousOption - a type similar to ! in Swift language. It's basically an Option which panics if dereferenced while containing None. no_std compatible.

2 unstable releases

Uses old Rust 2015

0.2.0 Sep 11, 2017
0.1.0 May 8, 2017

#400 in No standard library

Download history 11/week @ 2023-11-25 12/week @ 2023-12-16 2/week @ 2023-12-23 5/week @ 2024-01-06 6/week @ 2024-01-13 1/week @ 2024-01-20 4/week @ 2024-02-03 8/week @ 2024-02-10 27/week @ 2024-02-17 23/week @ 2024-02-24 22/week @ 2024-03-02 22/week @ 2024-03-09

95 downloads per month
Used in 3 crates (via rdedup-lib)

MITNFA license

9KB
106 lines

Dangerous Option

About

This crate provides DangerousOption - a type similar to ! in Swift language. It's basically an Option which panics if dereferenced while containing None. This is useful in cases one needs to initialize things a little bit later or when accesses are made via functions called from trusted library.

While such thing might look like a step back (there's a reason we don't have NULL pointers in Rust), there is still one advantage over classic approach of NULL-pointer exceptions (including manually unwrapping): the cause of the bug is usually not in the place where dereferencing happened but in the place where assignment happened. Since this type has only three, very unique methods for creating invalid value, those can be easily searched for and tracked.

This crate is no_std.

License

MITNFA


lib.rs:

This crate provides DangerousOption - a type similar to ! in Swift language. It's basically an Option which panics if dereferenced while containing None. This is useful in case one needs to initialize things a little bit later or when accesses are made via functions called from trusted library.

While such thing might look like a step back (there's a reason we don't have NULL pointers in Rust), there is still one advantage over classic approach of NULL-pointer exceptions (including manually unwrapping): the cause of the bug is usually not in the place where dereferencing happened but in the place where assignment happened. Since this type has only three, very unique methods for creating invalid value, those can be easily searched for and tracked.

It has also intentionally long name to prevent over-use. Also the methods creating dangerous state have longer names then those creating valid state.

Note: you should prefer dereferencing the DangerousOption and passing dereferenced value instead of passing the reference to DangerousOption itself. That way you'll decrease chance of making mistake.

Finally, it also provides an exception handler which allows customizing panic message, logging, etc. There is a default handler which just panics, but in contexts where there is a more concrete, known cause of invalid operation, overriding the message is encouraged.

This crate is no_std.

No runtime deps