u007d / bool_ext Goto Github PK

The current implementation of map seems to be nearly identical to Option<T>::map_or_else.

Hence I'd argue for said method to be renamed to map_or_else, and the addition of the missing map_or, map_or_default, unwrap, unwrap_or, unwrap_or_else, and unwrap_or_default functions- although the unwrap part of the last four names are up to bikeshedding, since bool isn't a container.

fn map_or<T, F: FnOnce() -> T>(&self, default: T, f: F) -> T;
fn map_or_default<T: Default, F: FnOnce() -> T>(&self, f: F) -> T;
fn unwrap<T>(&self, value: T) -> T; // panics if `self == false`
fn unwrap_or<T>(&self, if_true: T, if_false: T) -> T;
fn unwrap_or_else<T: Default, F: FnOnce() -> T>(&self, if_true: T, if_false: F) -> T;
fn unwrap_or_default<T: Default>(&self, v: T) -> T;

Currently, the API surface contains the following methods:

as_option_false
as_result_false
do_false
expect_false
ok_false
ok_false_with
ok_or_err_false
ok_or_err_false_with
some_false
some_with_false

All of which have a corresponding true variant. At first blush, this seems reasonable, after all, it follows the API of Option<T> somewhat, however, booleans can be trivially inverted via:

!(boolean).method()

// or

use std::ops::Not;
boolean.not().method()

I'd argue that in the general case, it'd be far more likely for someone to write some_bool.not().expect("Foo") than some_bool.expect_false("Foo"). Additionally, I'd argue that the smaller API space (10 less methods) would make the API easier to understand and use due to it's smaller size.

ps: if neither option above is okay, the first one because it requires parens around the whole expression before it, the latter because of an extra import, I'd suggest adding a fn BoolExt::invert(self) -> Self function that just does !self.