Date: Fri, 10 Jul 2026 09:03:29 +0100
It sounds to me like you are discussing part of the SG15 brief. A “package manager” (for want of a better phrase) has been a user request for as long as I’ve been on the committee. If you run through the SG15 archives you will see how this has unfolded. As far as I am aware, there was a lot of work on the ecosystem but the primary author was disappointed with the committee process and walked away. I encourage you to review the history.
I’m not going to reiterate at length here, but the main problem with package managers is the binary/source delivery problem. If you deliver a binary, it needs to be compliant with a vast array of build flags, which implies a combinatorial shipping situation, plus you get ABI issues. If you deliver source, it needs to be kept up to date with a variety of platforms. Both of these put a burden on voluntary contributors. The standard library resolves all these issues by demanding implementers maintain the standard, which is why it has come to be treated as a package manager. While at Creative Assembly I had experience of show-stopping library dependencies in Boost that failed when we upgraded implementation, requiring us to reimplement a library AND, due to company policy, preventing us from returning the benefit to Boost.
Cheers,
G
From: SG19 <sg19-bounces_at_[hidden]> On Behalf Of Vinnie Falco via SG19
Sent: 10 July 2026 04:22
To: sg19_at_[hidden]
Cc: Vinnie Falco <vinnie.falco_at_[hidden]>
Subject: Re: [isocpp-sg19] SG19 July monthly call
On Wed, Jul 8, 2026 at 11:37 AM Michael Wong via SG19 <sg19_at_[hidden] <mailto:sg19_at_[hidden]> > wrote:
...
During this meeting, a point was raised. There are organizations which cannot consume third party libraries. For example, downloading from GitHub or installing using vcpkg or conan. This is a legitimate concern. And if the C++ Standard does not offer a solution, it becomes an unfulfilled demand.
Which I just realized, is exactly the condition for market solutions to present themselves. This is what happened with static analysis tools. As long as the C++ Standard satisfies the implicit promise that it will use as the sole justification for standardization, that organizations cannot use third party solutions - no one else will step in to fill the demand.
I would bet that if C++ no longer offered std:: as a package manager, another entity will fill the gap. After all, the loss of supply does not diminish the demand. Perhaps a new working group would form, one whose sole purpose is to standardize library components with a different set of tradeoffs.
Food for thought.
I’m not going to reiterate at length here, but the main problem with package managers is the binary/source delivery problem. If you deliver a binary, it needs to be compliant with a vast array of build flags, which implies a combinatorial shipping situation, plus you get ABI issues. If you deliver source, it needs to be kept up to date with a variety of platforms. Both of these put a burden on voluntary contributors. The standard library resolves all these issues by demanding implementers maintain the standard, which is why it has come to be treated as a package manager. While at Creative Assembly I had experience of show-stopping library dependencies in Boost that failed when we upgraded implementation, requiring us to reimplement a library AND, due to company policy, preventing us from returning the benefit to Boost.
Cheers,
G
From: SG19 <sg19-bounces_at_[hidden]> On Behalf Of Vinnie Falco via SG19
Sent: 10 July 2026 04:22
To: sg19_at_[hidden]
Cc: Vinnie Falco <vinnie.falco_at_[hidden]>
Subject: Re: [isocpp-sg19] SG19 July monthly call
On Wed, Jul 8, 2026 at 11:37 AM Michael Wong via SG19 <sg19_at_[hidden] <mailto:sg19_at_[hidden]> > wrote:
...
During this meeting, a point was raised. There are organizations which cannot consume third party libraries. For example, downloading from GitHub or installing using vcpkg or conan. This is a legitimate concern. And if the C++ Standard does not offer a solution, it becomes an unfulfilled demand.
Which I just realized, is exactly the condition for market solutions to present themselves. This is what happened with static analysis tools. As long as the C++ Standard satisfies the implicit promise that it will use as the sole justification for standardization, that organizations cannot use third party solutions - no one else will step in to fill the demand.
I would bet that if C++ no longer offered std:: as a package manager, another entity will fill the gap. After all, the loss of supply does not diminish the demand. Perhaps a new working group would form, one whose sole purpose is to standardize library components with a different set of tradeoffs.
Food for thought.
Received on 2026-07-10 08:04:10