Closed oscbyspro closed 14 hours ago
It looks like Swift 6.0
(#91) lets us mark BinaryInteger.exactly(_:)
as borrowing
. So the borrowing get
problem must be solved. It also looks like Bool && @autoclosure () -> Bool
consumes the righ-hand-side, which is a bit unfortunate in the borrowing
case, but I can perhaps work around it using T.isSigned ? x : false
instead of T.isSigned && x
.
It looks like I missed one of the Nonzero/ilog2()
methods in (#90). I'll remove the version that doesn't reduce the number of failure modes. I.e. Nonzero<some UnsignedInteger>
guarantees non-optional results, but the other one doesn't.
I'll also fix a bug in one of my TestKit2
randomness utilities that may or may not cause spurious expectation failures.
LiteralInt
will conform Interoperable
with StaticBigInt
as its Stdlib
type.
I suppose I vaguely remember why LiteralInt
doesn't yet conform to Interoperable
. The StaticBigInt
model is slow, but it might be possible to fix the most common use cases by turning LiteralInt
into a small-integer-or-big-integer enum. In that case, it could no longer be conform to Interoperable
. I should explore that idea before I change it.
It's about 2x
faster to generate random U256
by filling MutableDataInt.Body
with an index loop instead of filling UnsafeRawBufferPointer
with Randomness/fill(_:)
. This approach does not change the performance of generating random UXL
instances, however.
Apparently, adding the Fibonacci/components()
method degrades the performance of an unrelated benchmark by about 2%
. It is consistent, so I thought I'd comment on it. My benchmark setup is not particularly serious at this moment, so this observation should probably be taken with a grain of salt, however.
I'll use this thread to document various minor changes.