Some questions about `Rect` and `BoundBox`

[colepoirier]

Rect and BoundBox

I'm curious if Rect should be constrained to have the same guarantees as BoundBox where p0 is the (x, y) values closest to negative infinity, and p1 is the (x ,y) values closest to positive infinity, then obviating the need for the BoundBox type which is essentially just a Rect which results in code duplication.

In that scenario would it then also make sense to define Rect as follows?

pub struct Rect {
    x_min: Int,
    y_min: Int,
    x_max: Int,
    y_max: Int,
}

Perceived BoundBox footgun

Something that I found to be a bit of a footgun with BoundBox is that 'empty, otherwise invalid [BoundBox]' is defined to have the value Int::MAX for p0, and Int::MIN for p1. Would it be better to define BoundBox as an enum sum type (like std::Option) as follows:

pub enum BoundBox {
    Valid(Rect),
    Invalid
}

Would this add too much overhead to what the BoundBox type is intended for? Does the user need to check the validity of the BoundBox regardless?

[dan-fritchman]

Totally agree the the BoundBox change is much better than what's in there now.

I'm less opinionated on the Rect representation. For some other shapes, e.g. a many-sided polygon, it's often actually nicer to store an offset "externally". The most common cell-instance transformation - translations - becomes a single-point move. In such a setup Rect would just become something like width, height or dx, dy.

You want to roll in at least the anti-foot-gunning?