Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Triaged labels.

cc @efortuna.

I agree that this is very surprising for a Rectangle in dart:math.
The default assumption would be Cartesian coordinates.

I'm 90% certain we had this discussion back when the code was going in, and you and Florian opted to have "graphics coordinates" in the default case. I can dredge up the email thread.... Back when we were writing this code I did a survey of other language's Rectangle classes, and by and large they used the computer graphics coordinates. The one exception being a specialized math third-party Python package, but again in the default Python rectangle y was down.

We could update the documentation... or change the implementation... I can see rationale for both sides, but adding the Cartesian coordinates does complicate the implementation (not that that should be the determining factor).

Even when I know it is "y down" coordinates, it still keeps surprising me :)
It's probably still the best choice, we just need to reduce the surprise, so the documentation need to be very explicit and up-front about it (like mentioned in first line of the class documentation, and again on the field getter and the constructor parameter).

This comment was originally written by ti...@xythings.com

Documentation is the main thing and I'm happy enough with it just being clear.
It takes a while reading the java Rectangle2D javadoc before it is obvious that it is a
y down implementation (though it is in the awt package).

On a more general level why is there a Rectangle class, and why is it in Math?
(sorry efortuna@google.com if this has been covered before) -
By Rectangle what is meant is a 'y down' rectangle because historically this was
used in raster, scanning implementations and this leaked into other code.
For these sorts of code the Rectangle implementation works but it should not
be confused with this being a general Rectangle, it is a very specific type of Rectangle.

If the package was math.graphics or graphics.math everything would be fine but
a math package implies for me a degree of abstraction, (I would prefer Point to
be Point2D and to use less significant dimension variables than x and y).
A rectangle implementation defined by points can provide max dimension methods
without loss of abstraction, but a constructor with width and height will need to
define the co-ordinate system first.
and so on...