On 14/05/2021 17:47, Ville Voutilainen wrote:
> I continue to think it's a mistake to start with the assumption that
> it's a good thing to strive for
> a set of "blessed" libraries. We already have dozens of those sets.

I didn't mean to suggest otherwise. I don't really have an opinion on
that; and, TBH, a large part the standard library itself should not
really be blessed by the committee IMHO, certainly these days.
iostreams, allocators, the map implementations, etc. But I digress...

> and then there are many others, like
> operating system package managers.

That's a good point, although not specific to C++. There is - IIANM -
some friction between different package management "worlds" which need
to overlap, e.g. OS distributions and language packages. The result are
often problematic: thousands or tens of thousands of OS packages for
each library of a bunch of languages (e.g. LaTeX and Fedora); or on the
other hand - no OS packaging except for the basic package management
client, in which case system installation becomes a multi-phase affair.

> If someone decides that "conan (or vcpackage) should
> and will win", fine, go work on conan (or vcpackage). I don't believe
> that'll change the overall discoverability of C++ libraries

* If a "C++ installation" must always include a package management
client, then by definition the developer is one step closer to discovery
using a package manager...
* If compilers mention the package manager in messages about missing
modules/libraries, developers are more likely actually go look those up
via the package manager.
* C++ supporting compilers and linkers may be able to tightly integrate
with a package manager. That means you might be able to, say, include
code or import modules from libraries which don't exist on your system
yet, with the package manager being invoked to retrieve them.
* IDEs may rely on cached package repository manifests to let you
autocomplete module names, or search modules from within the IDE -
without having to custom-implement this functionality for multiple
package managers.

I'm not saying I support the adoption of an official package manager,
but the above illustrates how this could increase
accessibility/discoverability of libraries/packages.