Add Span
equality (==
and !=
) operators.
#104280
Open
+54
−80
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This happens to allow us to deduplicate a bunch of
operator==
fromString
andVector
.It might be possible to remove explicit overloads in those functions, instead relying on implicit conversions to
Span
, but this is a bit risky compilation wise and thus out of scope for this PR. Will revisit this in a future PR.Span<char32_t>
comparison toSpan<char>
is somewhat questionable from aString
perspective, because it implicitly interprets theSpan<char>
aslatin1
, although it's usuallyascii
(still correct) or utf-8 (incorrect).Still, from a
Span
perspective this is entirely reasonable, because individual elements report equality. It is up to callers to differentiate encodings if they matter.Benchmark
This PR happens to optimize the equality checks of
Packed*Array
(fundamentally typedVector
). The reason is that the old implementation lacked amemcmp
optimization. I naively benchmarked a ~4x improvement on my computer. The improvement is likely to be better on modernx86_64
machines, due to wider SIMD support (up to 16x).I benchmarked this code:
This resulted in: