Improving flat containers interface.

base/containers/README.md

Index: base/containers/README.md
diff --git a/base/containers/README.md b/base/containers/README.md
index e64e8f3a637162d1b43b7d4df0f90e705289ecc9..5706156642cf45fafdbc89c5f2f761d7c5b08706 100644
--- a/base/containers/README.md
+++ b/base/containers/README.md
@@ -46,7 +46,7 @@ Google naming. Be sure to use the base namespace.
   * **base::small\_map** has better runtime memory usage without the poor
     mutation performance of large containers that base::flat\_map has. But this
     advantage is partially offset by additional code size. Prefer in cases
-    where you make many objects so that the code/heap tradeoff is good.
+    where you make many objects so that the code/heap tradeoff is good.
 
   * Use **std::map** and **std::set** if you can't decide. Even if they're not
     great, they're unlikely to be bad or surprising.
@@ -124,6 +124,10 @@ strategy and the memory access pattern. Assuming items are being linearly added,
 one would expect it to be 3/4 full, so per-item overhead will be 0.25 *
 sizeof(T).
 
+flat\_set/flat\_map support C++14 interface and a notion of transparent
+comparisons. Therefore you can, for example, lookup base::StringPiece in a set
+of std::strings without constructing a temporary std::string.
+
 ### base::small\_map
 
 A small inline buffer that is brute-force searched that overflows into a full