bring it into alignment with Rect methods that take Into<Point>.
Randomly noticed this, this patch doesn't do a full audit of the methods taking Point, should (we, or I) do such?
I went ahead and had a look through, here are the functions that take Points as parameters that we could consider
changing.
The nearest functions of ParamCurve, CubicBez, QuadBez, PathSeg, and Line.
Shape::winding, and Shape::contains trait methods.
The other variable, of various Point functions lerpmidpoint, distance, distance_squared
Here are some things I don't think should change, and reasons
While the new fn of QuadSpline takes a Vec<Point>, it takes ownership, turning it into an IntoIterator or something
Would force an allocation in collect.
bring it into alignment with
Rect
methods that takeInto<Point>
.Randomly noticed this, this patch doesn't do a full audit of the methods taking
Point
, should (we, or I) do such? I went ahead and had a look through, here are the functions that take Points as parameters that we could consider changing.nearest
functions ofParamCurve
,CubicBez
,QuadBez
,PathSeg
, andLine
.Shape::winding
, andShape::contains
trait methods.other
variable, of various Point functionslerp
midpoint
,distance
,distance_squared
Rect::union_pt
Ellipse::with_center
Affine::rotate_about
,pre_rotate_about
,then_rotate_about
.Here are some things I don't think should change, and reasons
new
fn ofQuadSpline
takes aVec<Point>
, it takes ownership, turning it into anIntoIterator
or something Would force an allocation in collect.