Result of Rect::from_points does not contain input points along right or bottom edge about euclid HOT 2 CLOSED

Sorry for the delay, the euclid stuff went under my radar for a while.

I agree that the behavior of contains and from_points put next to each other is confusing.
I believe that the [a..b[ behavior in contains is expected because of how it is used in servo/gecko especially with integer coordinates (Rect{ pos: (0, 0), size: (10, 10) } and Rect{ pos: (10, 0), size: (10, 10) } do not overlap).

Right now from_points is only used in webrender in a few places that don't seem to be negatively affected by the non-inclusiveness of the right and bottom edges of the rect.

With integer coordinates it would make sense that from_points inflate the size by 1 to match the semantics of contains. With floats I suppose that what would make sense is to inflate the size to the next floating point value (C/C++ nextafter which doesn't seem to exist in rust).

The generic specialization story in rust isn't great at the moment unfortunately, maybe we can paper over it with a trait that provides the next value implemented for all float and integer types.

from euclid.

Yeah, I ran into the float case myself when trying to generalize the helper method for this. I just went with One::one in my own program, but I wouldn't be happy putting that in euclid, and the proper solution with the nextvalue trait seems very heavyweight just for this one case. The simple thing here would be to add a note to the rustdoc of from_points that the results may be unintuitive because of the half-inclusion semantics.

from euclid.