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.
There are just far too many warnings issued for signedness differences
for it to be practical to cast every time.
Unsignedness was hiding the issue of dimensions being larger than
positions could express anyway.
It is not currently enabled as the exact semantics aren't really known,
but as we're likely to want something similar later then we shouldn't
throw the code away.
