Should juce::Path equality use approximatelyEqual?

1

Just ran into this when troubleshooting a caching bug for my blur library.

The float data underpinning juce::Path is currently tested fer equality with ==

bool Path::operator== (const Path& other) const noexcept    { return useNonZeroWinding == other.useNonZeroWinding && data == other.data; }

data is an Array<float> and operator== in ArrayBase looks like this:

        for (auto& o : other)
            if (! exactlyEqual (*e++, o))
                return false;

Issue should be reproducible like so:

juce::Path path;
path.addRectangle (1.0f, 1.0f, 1.0f, 1.0f);
float offsetX = juce::Random::getSystemRandom().nextFloat(); 
float offsetY = juce::Random::getSystemRandom().nextFloat(); 

auto copy = juce::Path (path);

// move the path by a float amount
path.applyTransform (juce::AffineTransform::translation (offsetX, offsetY));
// move it back
path.applyTransform (juce::AffineTransform::translation (-offsetX, -offsetY));

jassert (path != copy); // this fires for me

I’m working around it with a free function for equality, but outside of a JUCE fix, part of me is wondering if there’s a nicer way test equality of paths which avoids iteration/compare of each individual float value… ArrayBase already short circuits on size, but maybe Paths could short circuit on marker equality (100001, 100002, etc, which effectively behave as the “keys” of a path) or…