oscbyspro / Ultimathnum

Binary arithmetic reimagined in Swift
Apache License 2.0
9 stars 1 forks source link

Rework StdlibInt as StdlibInt<T> #96

Open oscbyspro opened 2 months ago

oscbyspro commented 2 months ago

It should be possible to make StdlibInt generic over FiniteInteger now that BinaryInteger has floating-point initializers (#25). So, what's the point of making it generic? Well, it lets us call functions generic over Swift.FixedWidthInteger in addition to Swift.BinaryInteger since StdlibInt<some SystemsInteger> can conform to it.

oscbyspro commented 3 days 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.

oscbyspro commented 3 days ago

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.

oscbyspro commented 2 days ago

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.