Just a thought, as this is anyway breaking the interface and requiring new implementation. Would it make sense to only support Update(ReadOnlySpan<byte> buffer) and change this in new version (1.5?). This interface looks like something that not many rely upon directly.

The interface is unimportant to me. I only changed it for completeness. Whatever the maintainers want is ok with me.

If breaking changes were being fully embraced, I would remove the array and array segment overloads. I assumed that binary compatibility was important to maintain, so I did not remove those.

Yes, it's maintainer's call, I think it already fails binary compatibility by adding a new method that old implementations don't implement.

I think it already fails binary compatibility by adding a new method that old implementations don't implement.

This is true, and I said as such in my initial message, but it's a much smaller breaking change than removing a bunch of redundant methods.

Yeah, avoiding breaking changes is one of the guiding principles for maintaining the library, and this PR currently lacks the motivation for the change.

It should be a fairly exotic use case for a consumer to implement their own CRC, so I think a breaking change could be acceptable here, but there needs to be a reason for doing so.

Motivation for the overall PR

It enables library users to reduce their allocations, resulting in significant performance gains.

Motivation for adding a span overload to the interface

Anyone not using the checksum classes directly, will not benefit from the performance gains of using spans.

Motivation for removing the redundant overloads

It simplifies the codebase and is a source-compatible change. If spans had been always been supported, these overloads would have never existed.

@piksel What do you want me to do?