I noticed the older matcher specs did this. My reason for taking a different approach came down to:

- I felt the other style tested the `expectations` behavior explicitly, which I wasn't writing
- The feature specs exercise the matcher via the expectation
- I've seen a lot of confusion (and been guilty of this myself in the past) on what the proper matcher protocol was/is. For example, I once believed the following overly simple, and incorrect matcher, was valid:

    ```ruby
    RSpec::Matchers.define :this_is_wrong do |expected|
      match do |actual|
        expect(actual.upcase).to eq expected.upcase
      end
    end
    ```

  It wasn't previously clear to me that `match`, and via extension, `matches?`, was supposed to return a boolean. I learned of the proper behavior when I read rspec/rspec-expectations#470:

  > Raising when the `actual` object is the wrong type (e.g. it lacks a necessary method) is not, because then you can't use it composably like this:
  >
  > ```ruby
  > expect(["foo", 2.3]).to include(
  >   matcher_that_expects_a_number,
  >   matcher_that_expects_a_string
  > )
  > ```
  > `matcher_that_expects_a_number` should return `false` from `matches?` when given `"foo"` rather than raising an error, and likewise, `matcher_that_expects_a_string` should return `false` rather than raising when given a number

My intent was to show the matcher protocol via the specs.