You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These require their inputs to have the same count, and they do not support operating on arbitrary slices of bit arrays. Requiring operands to have the same size does make sense, but disallowing slices seems overly restrictive.
Additionally, using operator syntax for these is rubbing me the wrong way -- I think I'd prefer to keep these as regular named methods for now, deferring the question of introducing operators pending future discussion. (I especially do not like the idea of adding more overloads for the slice-taking variants.)
Bitwise operations over arbitrary slices of bit arrays is very tricky to implement efficiently, so it seems preferably for the library to provide these out of the box.
In an ideal world, we could allow this with the following pleasant slicing syntax:
leta:BitArray,b:BitArraya[2..<10]|=b[5..<13]
Unfortunately, we do not live in an ideal world -- we have not figured out how to allow in-place slice-mutations like that without incurring unnecessary copy-on-write copies. But we can at least implement named top-level bit array mutations that take index ranges:
a.formBitwiseOr(in:2..<10, with:b[5..<13])
This isn't nearly as pleasant as the slicing syntax would be, but it's still quite readable, and it at least allows clients to use these operations.
extensionBitArray{mutatingfunc formBitwiseOr(with other:BitArray)mutatingfunc formBitwiseOr(with other:Slice<BitArray>)mutatingfunc formBitwiseOr(in range:someRangeExpression<Int>, with other:BitArray)mutatingfunc formBitwiseOr(in range:someRangeExpression<Int>, with other:Slice<BitArray>)mutatingfunc formBitwiseAnd(with other:BitArray)mutatingfunc formBitwiseAnd(with other:Slice<BitArray>)mutatingfunc formBitwiseAnd(in range:someRangeExpression<Int>, with other:BitArray)mutatingfunc formBitwiseAnd(in range:someRangeExpression<Int>, with other:Slice<BitArray>)mutatingfunc formBitwiseXor(with other:BitArray)mutatingfunc formBitwiseXor(with other:Slice<BitArray>)mutatingfunc formBitwiseXor(in range:someRangeExpression<Int>, with other:BitArray)mutatingfunc formBitwiseXor(in range:someRangeExpression<Int>, with other:Slice<BitArray>)mutatingfunc toggleAll()mutatingfunc toggleAll(in range:someRangeExpression<Int>)}
Replace the current list of operators with the above list of methods.
The text was updated successfully, but these errors were encountered:
I think we wouldn't want to ship 1.1 with the current operators, so I'm provisionally scheduling this for 1.1.
We may end up deferring adding the slicing variants to a future update though. (Just like we don't currently provide a way to do masking shifts/rotations on a slice of a bit array.)
BitArray
currently provides custom operators for the customary bitwise operations:These require their inputs to have the same count, and they do not support operating on arbitrary slices of bit arrays. Requiring operands to have the same size does make sense, but disallowing slices seems overly restrictive.
Additionally, using operator syntax for these is rubbing me the wrong way -- I think I'd prefer to keep these as regular named methods for now, deferring the question of introducing operators pending future discussion. (I especially do not like the idea of adding more overloads for the slice-taking variants.)
Bitwise operations over arbitrary slices of bit arrays is very tricky to implement efficiently, so it seems preferably for the library to provide these out of the box.
In an ideal world, we could allow this with the following pleasant slicing syntax:
Unfortunately, we do not live in an ideal world -- we have not figured out how to allow in-place slice-mutations like that without incurring unnecessary copy-on-write copies. But we can at least implement named top-level bit array mutations that take index ranges:
This isn't nearly as pleasant as the slicing syntax would be, but it's still quite readable, and it at least allows clients to use these operations.
Replace the current list of operators with the above list of methods.
The text was updated successfully, but these errors were encountered: