Date: Fri, 19 Jun 2026 12:09:14 -0400
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:
1.
*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.
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
*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.
On Fri, Jun 19, 2026 at 10:46 AM Phil Ratzloff <Phil.Ratzloff_at_[hidden]>
wrote:
> 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_at_[hidden]>
> *Sent:* Friday, June 19, 2026 2:47 AM
> *To:* sg19_at_[hidden] <sg19_at_[hidden]>
> *Cc:* Michael Wong <fraggamuffin_at_[hidden]>; Phil Ratzloff <
> Phil.Ratzloff_at_[hidden]>
> *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_at_[hidden]> 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_at_[hidden]> on behalf of Phil Ratzloff
> via SG19 <sg19_at_[hidden]>
> *Sent:* Thursday, June 18, 2026 5:15 PM
> *To:* Michael Wong <fraggamuffin_at_[hidden]>; sg19_at_[hidden] <
> sg19_at_[hidden]>
> *Cc:* Phil Ratzloff <Phil.Ratzloff_at_[hidden]>
> *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_at_[hidden]> on behalf of Vinnie Falco
> via SG19 <sg19_at_[hidden]>
> *Sent:* Thursday, June 18, 2026 3:08 PM
> *To:* Michael Wong <fraggamuffin_at_[hidden]>
> *Cc:* Vinnie Falco <vinnie.falco_at_[hidden]>; sg19_at_[hidden] <
> sg19_at_[hidden]>
> *Subject:* Re: [isocpp-sg19] Standardizing Graph concepts
>
> *EXTERNAL*
> On Thu, Jun 18, 2026 at 11:55 AM Phil Ratzloff <Phil.Ratzloff_at_[hidden]>
> 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
>
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
> <https://protect.checkpoint.com/v2/r01/___https://lists.isocpp.org/mailman/listinfo.cgi/sg19___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MzIxZDIyY2E4MzhjOGI3ZTRhZGI5ZGQxYWUxYWQwYzM6Nzo2ZGQzOjQ2ODNlNTAzNDkyYmRkMmVlYzI5M2ZiMmRmMmFjYzEwMzRhNTZiMmQ1OWFlNTg0NWQ3Njc2YzM2ZTE5OGQ5YWQ6aDpUOk4>
>
>
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:
1.
*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.
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
*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.
On Fri, Jun 19, 2026 at 10:46 AM Phil Ratzloff <Phil.Ratzloff_at_[hidden]>
wrote:
> 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_at_[hidden]>
> *Sent:* Friday, June 19, 2026 2:47 AM
> *To:* sg19_at_[hidden] <sg19_at_[hidden]>
> *Cc:* Michael Wong <fraggamuffin_at_[hidden]>; Phil Ratzloff <
> Phil.Ratzloff_at_[hidden]>
> *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_at_[hidden]> 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_at_[hidden]> on behalf of Phil Ratzloff
> via SG19 <sg19_at_[hidden]>
> *Sent:* Thursday, June 18, 2026 5:15 PM
> *To:* Michael Wong <fraggamuffin_at_[hidden]>; sg19_at_[hidden] <
> sg19_at_[hidden]>
> *Cc:* Phil Ratzloff <Phil.Ratzloff_at_[hidden]>
> *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_at_[hidden]> on behalf of Vinnie Falco
> via SG19 <sg19_at_[hidden]>
> *Sent:* Thursday, June 18, 2026 3:08 PM
> *To:* Michael Wong <fraggamuffin_at_[hidden]>
> *Cc:* Vinnie Falco <vinnie.falco_at_[hidden]>; sg19_at_[hidden] <
> sg19_at_[hidden]>
> *Subject:* Re: [isocpp-sg19] Standardizing Graph concepts
>
> *EXTERNAL*
> On Thu, Jun 18, 2026 at 11:55 AM Phil Ratzloff <Phil.Ratzloff_at_[hidden]>
> 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
>
> --
> SG19 mailing list
> SG19_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg19
> <https://protect.checkpoint.com/v2/r01/___https://lists.isocpp.org/mailman/listinfo.cgi/sg19___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MzIxZDIyY2E4MzhjOGI3ZTRhZGI5ZGQxYWUxYWQwYzM6Nzo2ZGQzOjQ2ODNlNTAzNDkyYmRkMmVlYzI5M2ZiMmRmMmFjYzEwMzRhNTZiMmQ1OWFlNTg0NWQ3Njc2YzM2ZTE5OGQ5YWQ6aDpUOk4>
>
>
Received on 2026-06-19 16:09:30