try_traits/
lib.rs

1//! Fallible versions of the std lib's traits.
2//! 
3//! For most cases, these traits are probably not what you need, and simply with careful use of
4//! generics you can use the builtin variants. And, when you can't, it's preferred to write "try"
5//! functions directly, such as [`File`](std::fs::File)'s [`try_clone`](
6//! std::fs::File::try_clone) method.
7//!
8//! Instead, these are meant to be used in APIs that require the ability to abstract over operations
9//! that could be fallible.
10//!
11//! # Why Some Traits Weren't Included
12//! There's a few reasons a core trait might not have been included:
13//! - They already completely support a form of failibility, and as such it wouldn't make sense to 
14//!   add a try version of them. (examples: `FromStr`).
15//! - Traits that it doesn't make much sense for them to be failible, such as [`core::marker`]
16//!   traits like [`Copy`] and [`Send`].
17//! - They simply hadn't been released yet when this was written. If this is the case, file an issue
18//!   (or submit a pull request!)
19#![no_std]
20#![forbid(unsafe_code)]
21#![allow(
22	clippy::unit_arg, // to allow for simple `Ok(x = y)` return values.
23	clippy::module_name_repetitions, // the core lib does this all over the place
24)]
25
26/// The value used for infallible conversions.
27pub type Infallible = core::convert::Infallible;
28
29pub mod clone;
30pub mod borrow;
31pub mod cmp;
32pub mod ops;
33pub mod hash;
34pub mod convert;
35pub mod default;
36pub mod iter;
37// Should we even include `slice`, `any`, `fmt`,	 or `future`?