EXTERNAL
Thank you all for this substantive and important exchange. Phil asked me to speak to the standardization rationale, so let me do that (I do try hard to stay neutral as I view my role is purely as a referee and whatever help I contributed was merey to set up the framework for exploring this work), and also address the broader questions Vinnie and others have raised.
Why standardize graphs at all?
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.
Vinnie's
std::filesystem analogy is instructive but I'd draw a different lesson from it. The strongest case for standardization isn't just portability over non-portable primitives — it's
vocabulary. std::string, std::vector, std::optional are all "pure C++" that could live on GitHub. They're in the standard because common vocabulary types enable ecosystem composability. The graph proposal's concepts
— adjacency_list, vertex_id, target_id(g,uv) — aim to be that vocabulary layer for graph programming, exactly as the Ranges concepts (input_range,
forward_range, etc.) are for sequential data. Without standardized concepts, every graph library is an island. With them, algorithms written against the concepts work with any conforming graph representation.
The usage concern is real and must be addressed.
I do not dismiss the point that Vinnie, Oleksandr, and Oliver have raised. A library with no deployment experience is asking the committee to standardize on faith. The Direction Group's guidance (P0592) emphasizes existing practice, and we should hold ourselves to that bar. Phil has acknowledged this honestly and is working to change it.
I would propose the following concrete path forward:
Maturation outside the standard. This is something recent meetings have surfaced. The graph library should establish real usage before we advance it beyond SG19. The Boost or Beman Project exists precisely for this purpose — providing infrastructure for standards-track libraries to gain deployment experience. I would encourage Phil and the co-authors to explore Beman inclusion, as well as continued distribution via vcpkg/Conan.
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
On the process question.
Vinnie asked about the decision-making process that led to writing the papers. The honest answer is that graph standardization has been part of SG19's work plan since the group's formation. The original P1709 paper was motivated by the observation that graph algorithms are among the most fundamental in computer science — as Oliver notes, Skiena calls them a unifying concept — and yet C++ has no standard graph vocabulary after 40+ years, while it has standard support for far more specialized facilities. That motivational argument remains sound. What has changed is our understanding of the evidence bar the committee rightly demands before saying Yes.
Thank you, Phil, for the ping, and thank you to Vinnie, Oliver, Oleksandr, and Chris for a highly constructive discussion.
However, I also acknowledge that the ABI and maintenance costs are permanent. The scale and complexity must be taken into acount and I agree entirely with Vinnie’s premise that the default answer for standardization must be "No". It has also been my personal opinion for a long time that standardizing nearly everything is a reflex action that the committee can no longer afford.
P.S. Phil, Vinnie is involved with the C++ Alliance and you are speaking already to the person who could advise you on getting this library into Boost, if it is a good idea.
Cheers.
With Andrew's help, I've reached out to the BGL (boost graph library) maintainers to see if we can work together somehow. Ideally, this would be a modern version of BGL and offer existing users a modern interface. They don't want to break their existing users, so it makes it difficult to imagine changing the existing library to support ranges, views, etc., and dropping legacy features like named parameters and property maps, without breaking existing code. That's why it seems like a good solution for the graph community if this were to become boost graph2, or something like that.
The maintainers are open to working together, but unfortunately, things aren't moving very quickly. I've suggested that we meet and discuss what that would mean, but it hasn't happened yet. I've only been in contact with the secondary BGL maintainer (Arnaud), and he hasn't been quick to arrange a meeting with me and the primary maintainer (Jeremy).
Arnaud, Andrew and I have agreed we'd like to meet for half a day at CppCon. I'm in the process to get funding from my company, and I'll give it a 50/50 chance that they'll send me. If they don't, I'll be looking for alternative funding.
I'm hoping Michael can help with this some, as he has contacts in the C++Alliance, that is overseeing boost.
From: Oliver Rosten <oliver.rosten@googlemail.com>
Sent: Friday, June 19, 2026 2:47 AM
To: sg19@lists.isocpp.org <sg19@lists.isocpp.org>
Cc: Michael Wong <fraggamuffin@gmail.com>; Phil Ratzloff <Phil.Ratzloff@sas.com>
Subject: Re: [isocpp-sg19] Standardizing Graph concepts
EXTERNAL
Graphs are not niche. They're used in a wide variety of disciplines and industries, and solve a wide diversity of problems.
I completely agree with this. In the renowned Algorithm Design Manual, Steven Skiena describes graphs as a unifying concept in computer science. In my experience, the more aware you are of graphs, the more you see them in code (often constructed implicitly). I would personally ultimately like to see both graph algorithms and graph containers become part of the standard.
A concern has been raised that the library isn't being used by anyone, which is true.
This is a huge concern for me. I think it may well be a major mistake to standardize a graph library if it does not have significant usage. Because graphs are so ubiquitous, and applied in so many different domains, designing a standardized facility that will stand the test of time surely needs years of refinement driven by application. If SG19 converges on a design, I would love to see it mature in the Beman project (or equivalent).
O.
On Fri, 19 Jun 2026 at 00:08, Phil Ratzloff via SG19 <sg19@lists.isocpp.org> wrote:Graphs are not niche. They're used in a wide variety of disciplines and industries, and solve a wide diversity of problems.
Not everyone uses them, but they fill an important role the computing environment, including machine learning.
From: SG19 <sg19-bounces@lists.isocpp.org> on behalf of Phil Ratzloff via SG19 <sg19@lists.isocpp.org>
Sent: Thursday, June 18, 2026 5:15 PM
To: Michael Wong <fraggamuffin@gmail.com>; sg19@lists.isocpp.org <sg19@lists.isocpp.org>
Cc: Phil Ratzloff <Phil.Ratzloff@sas.com>
Subject: Re: [isocpp-sg19] Standardizing Graph concepts
EXTERNAL
I'm still working on refinements to the papers and the reference library. My goal is to have them available for the next SG19 meeting. I've extended it to support vertices and edges in mapped containers. I'm also tightening up the overall interface and I'll also be working on reducing the overall size of the API.
I was asked years ago to split the paper up because people tended to not read large papers. The existing papers are just sections of the original.
CLRS is the clearest and best reference, according to Andrew Lumsdaine. He's been involved in the academic & research side of graphs more than I.
The library didn't exist before the papers. It is the reference implementation written in parallel with the papers.
A concern has been raised that the library isn't being used by anyone, which is true. I'm in the process to see if I can change that.
The design is influenced by boost graph library (BGL), which was written circa 2001 using C++98. This brings a modern interface with additional features and a similar design philosophy.
There's also an argument that not all users of C++ can use open-source libraries in github. Including functionality in the standand means they don't have to write it themselves. I don't know how much weight that argument carries for any library proposed for the standard.
Yes, Michael Wong.
From: SG19 <sg19-bounces@lists.isocpp.org> on behalf of Vinnie Falco via SG19 <sg19@lists.isocpp.org>
Sent: Thursday, June 18, 2026 3:08 PM
To: Michael Wong <fraggamuffin@gmail.com>
Cc: Vinnie Falco <vinnie.falco@gmail.com>; sg19@lists.isocpp.org <sg19@lists.isocpp.org>
Subject: Re: [isocpp-sg19] Standardizing Graph concepts
EXTERNAL
On Thu, Jun 18, 2026 at 11:55 AM Phil Ratzloff <Phil.Ratzloff@sas.com> wrote:Michael has been the one to promote a graph library as part of the standard as a part of the functionality used in machine learning, so I'll let him provide the details.
I am looking at P3127R1 which came out last year. This looks like a very well written set of papers. I note that the papers are split up into areas of concern: Overview, Background, Algorithms, and so forth. This is my preference yet there are conflicting opinions. One prominent officer said they prefer everything to be folded into one paper for ease of reading. I find this unpersuasive.
I learned something from P3127R1. "CLRS" refers to a specific tome which establishes a common vocabulary and set of concepts. It appears to be the API Schelling point which C++ graph libraries naturally converge to. That is, that graphs and their algorithms are an area of study by a relatively smaller group of practitioners who have already naturally converged on vocabulary and representation (vertex list I believe).
What was the motivation for writing these papers if the library already exists?
Let me give you an example. std::filesystem could have stayed in the ecosystem (i.e. Boost, or GitHub). Yet standardization brings measurable benefits. It provides a common API and a prescribed set of implementation behaviors so that it can work on every platform. This is necessary because filesystem is a portable API which wraps non-portable or operating system level operations.
Yet graphs and their algorithms are already portable as they can be expressed in pure C++ with no external libraries or operating system APIs.
I presume Michael is Michael Wong?
Thanks