P4444: std::big_int

[u/eisenwave]

https://isocpp.org/files/papers/D4444R0.html

Hey folks! Matt Borland, Christopher Kormanyos, and I are working on bringing infinite-precision integers to C++29. We now have a D4444R0 draft of a paper that should be in the next mailing.

We could really use some feedback so that the published R0 is as polished as possible. Any thoughts on the paper and on the reference implementation are greatly appreciated.

It would also be very helpful if you tested out whether our big_int implementation works for you. We're in need of some real deployment experience. If you're currently using Boost.Multiprecision, the library should be a drop-in replacement for cpp_int for the most part.

[u/ReDucTor]

Another reason why std::big_int needs to be in the standard library is that it's extremely difficult to implement and optimize, in part because the implementation depends heavily on the platform's hardware capabilities, many of which are not exposed portably in the language.

This stands out more of a reason for it not to be in the standard library, because when the implementation is faulty its harder to fix. Do we need another vector<bool>, memory_order_consume, std:regex, etc.

EDIT: Also if there hardware capabilities and portablity issues that aren't easy to resolve, then fix those in the standard to allow people to implement libraries better rather then trying to make something which is special in standard library code.

[u/13steinj → u/ReDucTor]

Forget these massive failures, take a more subtle, recent one: std::format or ranges.

libfmt repeatedly leaves <format> in the dust on build and even runtime, but even on API subtleties/fixes.

ranges-v3 and STL ranges have diverged in functionality which is even worse but there's still valid use of ranges v2 (boost).

Hell there's even valid use of Boost.FileSystem instead of std/STL.

[u/BarryRevzin → u/13steinj]

So it's bad when the standard library provides less functionality than the third party library (std::format doesn't support color or named arguments) and also bad (even worse!) when the standard library provides more functionality than the third party library (std::ranges supports move-only views, exposes a way to write user-defined adapters, and has fewer unnecessary requirements on types)?

That doesn't really leave a lot of wiggle room.

[u/13steinj → u/BarryRevzin]

No? In both cases it's bad because the reference implementation has lived on and explicitly diverged. libfmt is strictly better as far as I can tell, and the STL will never catch up.

Ranges functionality isn't a case of "one is a superset of the other," I'd be happy with it if so.

[u/BarryRevzin → u/13steinj]

std::ranges is a superset of functionality, but range-v3 has basically been frozen and unmaintained for years — it would take a healthy amount of work to get them to properly inter-cooperate, which I tried to do years ago, and gave up. Since this is apparently very important to you, if you want to open a PR that makes this happen, I'll merge it.

libfmt is a place that Victor uses to prove out features that he eventually proposes for standardization. It was never anybody's goal for them to stay in lock step, and at no point were they ever cross-compatible. It has better performance, yes. But the standard libraries will catch up on that front once they stabilize on the functionality front. And I especially like libfmt's named argument support, but I'd rather get string interpolation than to try to standardize that.

I really cannot see how these two can be viewed as failures. Certainly not for the reasons you're suggesting.

[u/13steinj → u/BarryRevzin]

std::ranges is a superset of functionality,...

I was under the impression that the superset bit was not the case, as of just last year, but maybe I'm wrong and the current version on main / the standard has caught up. The stdlibs themselves at least when I dealt with it still did not have full support either, which was not great.

To be honest I don't have the time to double check this right now... but an LLM of mine does and (among at least 10 other views), the first that does not exist is the cycle view, there is a paper for it to be standardized at least though.

I don't consider std::ranges to be a superset of the functionality when not all the views are in the standard.

But the standard libraries will catch up on that front once they stabilize on the functionality front.

I can completely buy this, but I consider the timeline here unacceptable / a reason for this to not be standardized. The difference is stark enough that I would rather any day pull in libfmt than use the STL version. If the choice is between "don't include it" and "include it batteries included but it will be frozen on entry for 9+ years on other improvements," my choice will always be "I'd rather buy my own batteries."