Date: Fri, 10 Jul 2026 12:46:08 +0300
>
> 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.
I don't buy that. Though I believe such organizations and policies exist,
I'm sure that these requirements don't have any meaningful reasoning behind
them. There's no point to believe that code written by STL maintainers is
any better than by anyone else. Actually, it's vice versa, there's no way a
project that's updated once in 3 years (at best) can be better than a
GitHub project that's updated as frequently as needed.
Anyway, those organizations can always review/vendor/contribute to
third-party libraries if they can't consume them as is. And if they really
don't want third-party code at any cost, well, they should write their own
solution from scratch and pay for it instead of making the whole C++
community pay for STL pollution that this approach causes.
I'm a strong believer that most parts of the current STL should not be
there. What language should provide is not a solution to everyone's (with
enough influence on committee) problem but an efficient way to communicate
between projects.
On Fri, Jul 10, 2026 at 11:04 AM Guy Davidson via SG19 <
sg19_at_[hidden]> wrote:
> 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]> 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.
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>
> 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.
I don't buy that. Though I believe such organizations and policies exist,
I'm sure that these requirements don't have any meaningful reasoning behind
them. There's no point to believe that code written by STL maintainers is
any better than by anyone else. Actually, it's vice versa, there's no way a
project that's updated once in 3 years (at best) can be better than a
GitHub project that's updated as frequently as needed.
Anyway, those organizations can always review/vendor/contribute to
third-party libraries if they can't consume them as is. And if they really
don't want third-party code at any cost, well, they should write their own
solution from scratch and pay for it instead of making the whole C++
community pay for STL pollution that this approach causes.
I'm a strong believer that most parts of the current STL should not be
there. What language should provide is not a solution to everyone's (with
enough influence on committee) problem but an efficient way to communicate
between projects.
On Fri, Jul 10, 2026 at 11:04 AM Guy Davidson via SG19 <
sg19_at_[hidden]> wrote:
> 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]> 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.
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>
-- Regards, Oleksandr Koval.
Received on 2026-07-10 09:46:27