Phil Pirozhkov

We kept `be_truthy`/`be_falsey` in 4.0, so the following is still possible: ```ruby # passes expect(123.infinite?).to be_falsey expect(-Float::INFINITY.infinite?).to be_truthy ``` However, it's not obvious which predicates can return non-boolean values in...

Added a warning [here](https://github.com/rspec/rspec-expectations/pull/1301/commits/65a32bc4b6c8811171849af3b01bc9d04b857114#diff-aae753a2dd057c1daa71ef46302939a7b18eba3cd761ddda7221ef0bb793e279R89): ```ruby expect(-Float::INFINITY).to be_infinite ``` ``` `infinite?` returned neither `true` nor `false`, but rather `-1` ``` for easier migration to strict mode ones. ```ruby config.set_strict_predicate_matcher_mode :be_infinite, :truthy...

@JonRowe do you agree with the expected behaviour section here? > doc_string which is the first argument of example, must be string object It confuses me when the first argument...

Sounds good, and no worries. Thanks for your contributions!

@bclayman-sq Certainly. We're always watching. 👀

Seems similar to #2489, can you please check if it's not a duplicate?

Do those specs fail when you run it without `--bisect`, @cmrd-senya ?

Does it make sense to rebase this on `4-0-dev` and get rid of Ruby < 2.3 checks? @JonRowe do we have a timeline for 4.0 release?

It may take a while. We're making our best effort, but often times life and daily job intervenes, and it [may take longer](https://ossert.evilmartians.io/rspec-expectations). Processing has improved this year, though: 

@matthewrudy @pboling Fixed Ruby 2.1 support, build is green now. Do you think it's ok to introduce breaking changes even though the gem has not reached 1.0 yet?