Should we add support for Boost.int128 to the library?

[akikurichan]

Currently, we are using several different methods to simulate the int128 data type on operating systems that don't support it. Boost.int128 was recently introduced, and I think we should consider adding it as an option. What do you guys think?

[JkarVN]

Boost.int128 is still a candidate library. In my opinion, we should avoid rushing and wait for its official inclusion in the Boost suite

[akikurichan]

I think we should merge pcg-cpp and pcg-next. What do you think?

[JkarVN]

I think merging the two branches is very feasible.

[bhaller]

Adding a dependency on Boost would, of course, be a problem for all projects that don't use Boost, including mine. If you do this, please make sure it is an opt-in feature that doesn't break this project for other users.

Merging pcg-cpp and pcg-next would defeat the whole purpose of having those be separate: that some projects, such as mine, need C++11 and cannot move forward at this point in time. You only just created the pcg-cpp versus pcg-next division, for that very purpose. Why are you now proposing merging them, with no discussion of how you're going to continue to support users who depend on pcg-cpp?

These proposals seem like random, unplanned, ill-conceived stabs in the dark. If Total-Random goes in this kind of direction, I guess I'll just have to revert back to the original PCG repo, which would be unfortunate.

Can I suggest: focus on fixing actual issues and merging in actual PRs from the original repo, to produce a polished, bug-free fork that everybody can use, and then... just maintain it, and don't break it. That is what the community needs.

[JkarVN]

Thank you for your candid feedback. I completely understand your concerns regarding dependency bloat and backward compatibility. Our goal is to improve the library, not to make it harder to use for long-time supporters like yourself.

To clarify our recent shift in thinking:

• Optional Features, Not Hard Dependencies: The integration of Boost (specifically Boost.Int128) is being designed as an opt-in feature. If your project doesn't use Boost, the library will continue to function exactly as it does now. We are using preprocessor macros to ensure that these "next" features only activate if the user explicitly enables them.

• Unified Support for C++11: We realized that maintaining two entirely separate branches (pcg-cpp and pcg-next) might actually lead to more fragmentation and maintenance overhead. By merging them, we plan to use feature detection to support C++20 optimizations while keeping C++11 as the baseline requirement.

• Confidence in Macro Design: After a deeper technical review, we are no longer hesitant about designing a robust macro system. We’ve found that using macros to handle versioning doesn't significantly impact compile times, and it allows us to provide clean fallbacks for older standards while still leveraging modern C++ features where available.

• Maintenance Focus: You're right—stability is paramount. As a small team of two working on this alongside other major projects (like our GuinevereFramework), we’ve realized that a single, well-architected codebase is much easier for us to maintain and keep bug-free in the long run.

• We apologize if our recent proposals felt erratic. Our intent is to create a polished, "evergreen" fork that merges the best of the original repo with necessary modern fixes, without breaking the core promise of C++11 compatibility.

• We’ll be more careful with any potential breaking changes and will ensure major architectural shifts are clearly documented as optional. We appreciate your patience as we navigate this on our weekends!

Best regards,

[bhaller]

OK, that is somewhat reassuring.