Bitwise-and operations were added because the result of such an operation will always be positive.

Just because we can, doesn't mean we should, and this would be the only operator that mixed BigUint with signed primitives.
(Well, except for shifts, but the standard library already set the precedent for that oddness...)

You're right; I hadn't realized that the other operations would have such an issue until after I'd written the BitAnd implementation, and I figured it'd be better to ask before deleting it. I'll happily do so now if it doesn't make sense to include.

Bitwise-and operations were added because the result of such an operation will always be positive

Correct me if I'm wrong, but ANDing -1 (as a BigInt) with any number (in two's complement) should be a no-op, therefore returning the original number with whatever sign it had before the operation. Does this library use another encoding other than two's complement? (sorry for this question, I'm new to Rust and this repo)

Update: wait I realized my mistake lol. The PR is about mixed-type bit ops, so a primitive -1 would have a finite popcount equal to its wordsize, therefore always returning an unsigned number

I still think the mixed signed-ness is too confusing, let's drop that.