Open oscbyspro opened 2 months ago
Hm. I suppose the tricky part is that Swift.BinaryInteger
kind of requires that StdlibInt<IXL>.Magnitude
is StdlibInt<IXL>
. This is one of the differences between the two projects. There are multiple solutions to it, but I'll take a moment to consider whether there's any way to create a well-behaved big Swift.UnsignedInteger
first.
Hm. I have another idea I want to explore. I could add dedicated DoubleInt.Stdlib
and InfiniInt.Stdlib
types rather than overabstracting StdlibInt<T>
. Imagine additional modules like, InfiniIntStdlibKit
or DoubleIntStdlibKit
. Using this approach, I could simultaneously conform DoubleInt
and InfiniInt
to Interoperable
in the new modules.
So I'm trying to deduplicate the implementation of InfiniInt.Stdlib
and DoubleInt.Stdlib
using an AdapterInteger
protocol. I'm not sure that's possible, however. Swift.FixedWidthInteger
adds a bunch of default implementations, which means that writing defaults in terms of AdapterInteger
results in ambiguity. Both refine Swift.BinaryInteger
and neither have priority over the other. Maybe I'll just have to accept the boilerplate.
It should be possible to make
StdlibInt
generic overFiniteInteger
now thatBinaryInteger
has floating-point initializers (#25). So, what's the point of making it generic? Well, it lets us call functions generic overSwift.FixedWidthInteger
in addition toSwift.BinaryInteger
sinceStdlibInt<some SystemsInteger>
can conform to it.