I would like to offer a (non-substantive) vote that graphs continue to
incubate outside of any standardization effort.

My primary issue with many such facilities being included in the standard
is that even if the *API principles *(core nouns/verbs) are sound, the idea
of what constitutes "general usage" is ultimately constrained to the use
cases of participants in the room. Even if everyone needs a notion of a
"graph," the software requirements that dictate how the implementation must
proceed can be quite different. Some might need a graph strictly for
offline processing (e.g. the machine learning use cases cited, evaluating a
dependency graph for an asset processing system or a build system, etc.).
Others may need the graph for real-time processing (evaluating a behavior
tree for an AI in a video game, performing a path-finding routine on a
navigation mesh, etc.). Even within those use cases, I've often found that
several implementations of a similar graph API were needed to accommodate
different requirements (is the graph statically compiled, can it mutate
during traversal, does it need to be thread safe, do graph nodes require
stable addressing, etc.). What appears to occur a good deal with
standardization efforts in the past is that the implementation as delivered
in actual working C++ libraries tends to bias significantly towards a
specific set of use cases, causing a "general purpose idea" to suddenly
have a particularly niche target audience, except now with the maintenance
burden of standardization and implementation by all compiler vendors.
Meanwhile, users are on the hook for figuring out specifically what
tradeoffs were made by each compiler vendor in matters of decisions that
are underspecified since they don't impact the standardized contract. The
alternative might be to support *all *such implementation constraints by
adding complexity/surface-area to the API itself in the form of
flags/options, lower-level control, and so on. This adds a complexity
tradeoff to the mix, and probably constitutes a bikeshed enclosing a
veritable labyrinth of decisions.

To give another example: std::random -- nice in principle, but
distributions built on top of it lack platform-determinism which renders it
unusable for a large number of applications. The recommended RNG engine
also has far too much state for use in memory-constrained environments. I
don't think this is the fault of the committee or any particular
implementation -- moreso that the actual requirements for random number
generation on a given project are often far more nuanced than just "is it
sufficiently random". This nuance is what makes standardization difficult.
I'm not trying to say that nothing is worth standardizing if it doesn't
satisfy "everyone" (because we would then standardize nothing), but that
before standardization, the true extent of a feature's generalizability
should somehow be measured and subsequently weighed against the costs. I
would suggest that weak points in the STL came about because the measure of
"generalizability" was either inaccurate or incorrectly under-weighed
relevant implementation nuances.

A user-space community-oriented library, on the other hand, has a ton of
advantages. It can pivot at the discretion of its users. It can release on
its own cadence. It's implementation decisions are clearly spelled out in
code (as opposed to the STL which may diverge across platforms and
toolchains). Circling back to the idea of graph standardization again,
perhaps an important point to raise is if there are future downstream
standardization efforts that would build *on top of *such a graph
abstraction -- and with that, I would probably be one to ask, "should
*those *libraries perhaps also be better served in user space as well?"

Jeremy

On Fri, Jun 19, 2026 at 2:58 PM Jens Maurer via SG19 <sg19_at_[hidden]>
wrote:

>
> On 6/19/26 18:09, Michael Wong via SG19 wrote:
> > SG19's charter explicitly includes "optimization for graph programming"
> alongside linear algebra, array operations, and machine learning support.
> Graph algorithms are foundational infrastructure for ML workloads — neural
> network architectures are directed graphs, dependency resolution in
> training pipelines is topological sorting, knowledge graphs are
> increasingly central to AI systems. The question of whether graphs are
> "general-purpose enough" for the standard must be evaluated against this
> backdrop: the committee has already decided, by chartering SG19, that this
> domain merits standardization attention.
>
> Study Groups are created by act of the convenor, thus the existence
> of a Study Group does not imply that "the committee has decided"
> anything at all.
>
> > 2.
> >
> > *Separate the concepts from the containers and algorithms.* The
> strongest near-term standardization case may be for the graph /concepts/
> alone — a minimal vocabulary that allows the ecosystem to converge, without
> committing to specific algorithms or containers. This is analogous to how
> the Ranges proposal began with foundational concepts before the full
> |<ranges>| library. If the concepts prove useful and stable in practice,
> the algorithms can follow later with much lower risk.f
>
> A named concept is effectively immutable after it has been standardized,
> so I don't think the approach to have concepts without use of those
> concepts is getting us a good end result.
>
> As far as I remember, the ranges concepts did come with a selection
> of ranges algorithms, too, which served as proof that the concepts
> were viable. Yes, more ranges algorithms were added later.
>
> Jens
>
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
>