we're trying to move away from mutating operators.
also, we do the bad thing of just renaming the non-mutating operator
given it appears no one is using the mutating operator in our code bases
anyway...
we're moving away from mutating operators so this is somewhat
out-of-place. it's not a huge functional change though as there are
enough locations where the internal representation of point/extent are
assumed that we just do it through the members.
the meaning of the array values weren't particularly clear. are they
point-point, point-extent, something else? also the implementation was
horribly incorrect for whatever it claimed to be doing. so we remove the
function entirely to avoid the aforementioned ambiguity.
the union accessors x,y,w,h were predicated on the dimension being 2.
for higher/lower dimensions this resulted in the incorrect variable
being returned.
rather than do something fancy with unions and coord storage type for
access to the underlying data we force the user to acknowledge the split
storage of point/extent.
unfortunately we have pretty shitty names for the components as a
result.
it's too problematic to retain signedness distinctions between base
points and region extents. just use the same types, but retain the
named typedefs for compatibility.
It is unclear what this operator was supposed to do, and triggers a
number of sign and type warnings. Re-add later if necessary under a more
descriptive name.
