Tracking issue for invariants on BezPath

[derekdreery]

Should we relax the current restrictions on BezPath (must start with moveto, and allow segment straight after closepath)

[anthrotype]

is this in order to match the semantics of SVG's M command which can be omitted?
I think some kurbo clients may rely on the fact that BezPath constructor guarantees the invariant of always starting with a PathEl::MoveTo, and not do additional validation; if you relax that things may break in unexpected ways.
Maybe it would be safer to have a different type that follows the SVG moveto semantics that in turn wraps a BezPath.

[raphlinus]

The motivation is partly to match SVG's semantics, and partly to represent paths that can be encoded more efficiently (in Vello) when the endpoint of one subpath matches the start point of another - in that case, in all APIs I've researched (going back to PostScript), the moveto of the second subpath can be elided.

I'd rather not have a proliferation of types if that can be avoided. If there is actual breakage, I'd like to know about it and figure out the best solution to address it. One idea that comes to mind is a validation method that can be applied when stricter semantics are needed, otherwise the relaxed semantics would be in place.

One problem that occurs to me about allowing (0.0, 0.0) as a default start point when there is no initial moveto is that paths are no longer translation invariant, at least by straightforward element-wise application of the transform.

[derekdreery]

Hmm perhaps I'm convinced that the first MoveTo should stay, given what's been said.

Rather than remove invariant states, we could either prevent them (in this case checking the first element is MoveTo whenever it is changed). Getting mutable access to the elements would no longer be possible though, as the first element could be swapped out.

Yet another option would be just to have the start point as a field on BezPath, and remove it from elements.