buffer.compare

[Elentium]

Rendered

This PR proposes adding buffer.compare(b1, offset1, b2, offset2?, count?) to the standard buffer library. It performs an in-place, three-way lexicographic comparison over the underlying memory of two buffers, mimicking C memcmp. It returns 0 if the buffers are equal, a negative integer if b1 is less than b2, and a positive integer if b1 is greater.

[alicesaidhi]

I think it'd be nice if we can also specify the offsets and length of the parts we want to compare

[Bottersnike]

I think the "Ranged comparison support" alternative is a much more powerful option, and with the suggested parameter list would be able to gracefully fall back anyway. I suspect (b1, offset1, b2, offset2, length) might be more consistent with the rest of the buffer library though.

[Elentium]

I think the "Ranged comparison support" alternative is a much more powerful option, and with the suggested parameter list would be able to gracefully fall back anyway. I suspect (b1, offset1, b2, offset2, length) might be more consistent with the rest of the buffer library though.

Yeah, though imo (b1, b2, offset1?, offset2?, count?) would be more convenient in cases where you need full 0 to end comparison and you can just pass the 2 buffers

[InfraredGodYT]

I think the "Ranged comparison support" alternative is a much more powerful option, and with the suggested parameter list would be able to gracefully fall back anyway. I suspect (b1, offset1, b2, offset2, length) might be more consistent with the rest of the buffer library though.

Yeah, though imo (b1, b2, offset1?, offset2?, count?) would be more convenient in cases where you need full 0 to end comparison and you can just pass the 2 buffers

Considering the existence of buffer.copy(target, targetOffset, source, sourceOffset, count), I also think buffer.compare(b1, offset1, b2, offset2, length) makes more sense to add.

[Elentium]

Alright that makes sense, I will update the rfc tomorrow

[itsmath]

Sort of unrelated, but can we get bitwise ops for buffers too (maybe implemented with SIMD)? A lot of the use cases I have for comparing buffers also benefit from bitwise ops. Just as a quick example, bitflags with more than 32 bits, currently you have to do a Luau loop and do it in chunks of u32

[InfraredGodYT]

Sort of unrelated, but can we get bitwise ops for buffers too (maybe implemented with SIMD)? A lot of the use cases I have for comparing buffers also benefit from bitwise ops. Just as a quick example, bitflags with more than 32 bits, currently you have to do a Luau loop and do it in chunks of u32

That would need to be a separate RFC entirely.

[Elentium]

Sort of unrelated, but can we get bitwise ops for buffers too (maybe implemented with SIMD)? A lot of the use cases I have for comparing buffers also benefit from bitwise ops. Just as a quick example, bitflags with more than 32 bits, currently you have to do a Luau loop and do it in chunks of u32

That would be a game changing feature, Im interested to see your rfc on it if you decide to make one

[Elentium]

Alright updated it a bit

[nnullcolumn]

I think the "Ranged comparison support" alternative is a much more powerful option, and with the suggested parameter list would be able to gracefully fall back anyway. I suspect (b1, offset1, b2, offset2, length) might be more consistent with the rest of the buffer library though.

Yeah, though imo (b1, b2, offset1?, offset2?, count?) would be more convenient in cases where you need full 0 to end comparison and you can just pass the 2 buffers

Considering the existence of buffer.copy(target, targetOffset, source, sourceOffset, count), I also think buffer.compare(b1, offset1, b2, offset2, length) makes more sense to add.

i don't think the api needs to be designed around buffer.copy, since that function requires the first three arguments anyways. i think it should be (b1, b2, offset1?, offset2?, count?).