Googletest export

Suggest using generic lambdas for composing macros.

Long chains of macros hurt legibility; generic lambdas are an easy way to abbreviate them, but are not an obvious solution to casual users.

Compare:
EXPECT_THAT(f(), ElementsAre(
    Property(&MyClass::foo, Property(&OtherClass::bar, Contains("x"))),
    Property(&MyClass::foo, Property(&OtherClass::bar, Contains("y"))));
to:
EXPECT_THAT(f(), ElementsAre(HasFooBar("x"), HasFooBar("y")));
PiperOrigin-RevId: 336870137

1 files changed, 16 insertions, 0 deletions

diff --git a/googlemock/docs/cook_book.md b/googlemock/docs/cook_book.md
index f8e9a50f..817d5cab 100644
--- a/googlemock/docs/cook_book.md
+++ b/googlemock/docs/cook_book.md
@@ -859,6 +859,22 @@ using ::testing::Not;
                           NULL));
 ```
 
+Matchers are function objects, and parametrized matchers can be composed just
+like any other function. However because their types can be long and rarely
+provide meaningful information, it can be easier to express them with C++14
+generic lambdas to avoid specifying types. For example,
+
+```cpp
+using ::testing::Contains;
+using ::testing::Property;
+
+inline constexpr auto HasFoo = [](const auto& f) {
+  return Property(&MyClass::foo, Contains(f));
+};
+...
+  EXPECT_THAT(x, HasFoo("blah"));
+```
+
 ### Casting Matchers {#SafeMatcherCast}
 
 gMock matchers are statically typed, meaning that the compiler can catch your