C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::big_int

From: Tiago Freire <tmiguelf_at_[hidden]>
Date: Tue, 14 Apr 2026 13:00:04 +0000
And updated version of the paper is here:
https://isocpp.org/files/papers/P3161R5.html

> I think you're also in a tough position because the paper isn't broken down into smaller pieces.

I wanted to defend 1 paper on 1 topic instead of 4. Feels like a waste of committee time given that they are related to the same thing, and if only one gets accepted and not the other the feature is very much incomplete and does not achieve the stated goals.

I’ve had a look at your “division paper”, I have some comments about it, but I will go trough those later when I have more time, and perhaps in a separate more relevant thread.


From: Jan Schultke <janschultke_at_googlemail.com>
Sent: Tuesday, April 14, 2026 11:36
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: C++ Proposals <std-proposals_at_[hidden]>; Towner, Daniel <daniel.towner_at_[hidden]>
Subject: Re: std::big_int



On Fri, 3 Apr 2026 at 11:13, Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
To be honest I haven't made much progress lately because I haven't been feeling very motivated due to frustrations with the process.
I will try to force myself to get an update on the paper in the upcoming weeks, and perhaps also compile a list of papers that are now dependent on P3161 being accepted (which is currently mounting).

Thanks for your continued effort.

I will try to do what I can, but I don't want anyone to be disappointed.
Last meeting made it very clear to me that I need to be in the room to explain the same objections over and over again, and I simply don't have the resources to skip work and family to fly around the world and stay at a hotel for a week because maybe the paper might be discussed or not, and who knows how many times I have to rinse and repeat.

That's unfortunate. If you need someone to champion the paper in person though, I can help with that.

I think you're also in a tough position because the paper isn't broken down into smaller pieces. std::mul_wide (should be std::widening_mul now though) is a total no-brainer, and the design is obvious. It probably would have been in the standard already if it was separated. std::carrying_add and std::borrowing_sub could be one separate paper too. Last but not least, anything related to division would be in a third paper.


Received on 2026-04-14 13:00:18