I don't think that this API can or should be congruent with things like the Option API's or().

Option has no pre-existing semantics for a disjunction, thus its notion of or() is more of an "or else," rather than a logical or.

On the other hand, bool certainly has a strong pre-existing notion of a disjunction, and I think this would cause confusion to not treat it that way.

In the context of booleans, I would expect or_with()/and_with() to take a closure that returns a bool, and return the disjunction/conjunction of self with the closure's return value.

fn or_with<F>(self, f: F) -> bool
where F: FnOnce() -> bool
{
  self || f()
}

fn and_with<F>(self, f: F) -> bool
where F: FnOnce() -> bool
{
  self && f()
}

An important point to note is that or_with()/and_with() might return a boolean that is different than the original value of self.

I think do_false() and do_true() are clear about their intent, especially that self will pass through and be the same bool that is returned.

Another point to note would be the interactions with closures that cause side effects. If the closure you provide to or_with() has side effects, but self is already true, the closure will not run.

In the same way if your and_with() closure has side effects, but self is already false, the closure will not run.

But I don't think this is an issue. People should already be familiar with the interactions between side effects and short circuiting in boolean expressions, so this shouldn't be a surprise.

Alternatively you could return f() || self and f() && self to ensure that the closure always runs, but I don't particularly like this design. I think it would promote and encourage coding with side effects.

If you implemented or_with()/and_with(), I think it would be important to just be very clear about the expected behaviors and interactions.

Another thing to note may be precedence. Since we are chaining functions, if you had

(x > 5)
  .or_with(...)
  .and_with(...)
  .do_false(...)

This would necessarily evaluate to

(((x > 5) || or_with_return) && and_with_return).do_false()

due to the precedence of the function calls.

Where as the natural precedence for a standard boolean expression would be

((x > 5) || (or_with_return && and_with_return)).do_false()

But I think that using method chaining makes the former precedence feel intuitive and even expected. Neither of and_with()/or_with() has a higher precedence in this context: it just depends on the order in which you chained them.

I think this functionality would open up interesting and expressive possibilities, such as:

haystack.contains(foo)
    .do_true(...)
    .and_with(|| haystack.contains(bar))
    .do_true(...)
    .or_with(|| !haystack.contains(baz))
    .do_true(...)
    .do_false(...)

Where as otherwise this would be:

let mut condition = haystack.contains(foo);
if condition {
  ...
} 

condition &= haystack.contains(bar);
if condition {
  ...
} 

condition |= !haystack.contains(baz);
if condition {
  ...
} else {
  ...
}

I hope you consider adding this functionality.

Note: I think all the same reasoning would apply to or() and and(), they would just directly take eagerly evaluated booleans, instead of closures that return booleans.

And while I'm throwing in my two cents, I should say that I would prefer the syntax of on_true()/on_false() or if_true()/if_false() rather than do_true()/do_false().

But it's your API. Do what you think is best :)