Add non-member non-mutating methods for common gfx::Rect operations.

ui/gfx/rect.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Defines a simple integer rectangle class.  The containment semantics
 // are array-like; that is, the coordinate (x, y) is considered to be
 // contained by the rectangle, but the coordinate (x + width, y) is not.
 // The class will happily let you create malformed rectangles (that is,
 // rectangles with negative width and/or height), but there will be assertions
 // in the operations (such as Contains()) to complain in this case.
@@ skipping 57 matching lines @@
 };
 
 inline bool operator==(const Rect& lhs, const Rect& rhs) {
   return lhs.origin() == rhs.origin() && lhs.size() == rhs.size();
 }
 
 inline bool operator!=(const Rect& lhs, const Rect& rhs) {
   return !(lhs == rhs);
 }
 
+inline Rect Intersection(const Rect& a, const Rect& b) {

[sky, 2012/10/25 23:31:53]

I think we need more descriptive names otherwise we can easily conflict. Maybe
IntersectRects. Is there a compelling reason to inline these?

[danakj, 2012/10/26 00:16:04]

Sure, though I thought the same and enne@ convinced me otherwise. Rect does not
implicitly convert to/from anything else, so what would we conflict with?
Nope, other than they are small. Will move to the .cc.

+  Rect result = a;
+  result.Intersect(b);
+  return result;
+}
+
+inline Rect Union(const Rect& a, const Rect& b) {
+  Rect result = a;
+  result.Union(b);
+  return result;
+}
+
+inline Rect Subtraction(const Rect& a, const Rect& b) {
+  Rect result = a;
+  result.Subtract(b);
+  return result;
+}
+
 #if !defined(COMPILER_MSVC)
 extern template class RectBase<Rect, Point, Size, Insets, int>;
 #endif
 
 }  // namespace gfx
 
 #endif  // UI_GFX_RECT_H_