@rmanoka I'd love some feedback here to make sure I haven't accidentally tied myself into knots w/r/t/ types – the existing tests weren't modified and all pass, however.

The main reason we need this is in order to implement a unary union: a t::f(g) -> multipoly bool op isn't an obstacle, but the current restriction which says t and g must be the same type (Polygon or MultiPolygon) does cause an issue, because it requires an intermediate conversion of Polygon to MultiPolygon during the fold and reduction ops, and those conversions needlessly allocate because MultiPolygon is Vec under the hood.

WDYT?

Would it be clean to implement new traits: Intersection, Union, Difference similair to our existing Intersects, Contains; then impl Polygon<T>: Intersection<Polygon<T>> and also Polygon<T>: Intersection<MultiPolygon<T>> and the impls take care of routing to the necessary impl.

So for eg. the clip would be LineString<T>: Intersection<Polygon<T>> ?

Yeah I'm open to it – where would that leave the public boolops API?

I suppose we can deprecate the bool-ops trait, and re-route to the new traits. The method names could probably remain same for ease, and we can provide new alias too.

I don't think we need this anymore now that #1234 has merged. I think it also enables the major cascaded union use case: https://gist.github.com/urschrei/cd80b4d2ec3c75f12fa541a5bdbf6489

I totally forgot about this one. Sorry — we should have merged it months ago.