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]<mailto: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]<mailto:sg19-bounces_at_[hidden]>> on behalf of Phil Ratzloff via SG19 <sg19_at_[hidden]<mailto:sg19_at_[hidden]>>
Sent: Thursday, June 18, 2026 5:15 PM
To: Michael Wong <fraggamuffin_at_gmail.com<mailto:fraggamuffin_at_[hidden]>>; sg19_at_[hidden]<mailto:sg19_at_[hidden]> <sg19_at_[hidden]<mailto:sg19_at_[hidden]>>
Cc: Phil Ratzloff <Phil.Ratzloff_at_[hidden]<mailto: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]<mailto:sg19-bounces_at_[hidden]>> on behalf of Vinnie Falco via SG19 <sg19_at_[hidden]<mailto:sg19_at_[hidden]>>
Sent: Thursday, June 18, 2026 3:08 PM
To: Michael Wong <fraggamuffin_at_[hidden]<mailto:fraggamuffin_at_[hidden]>>
Cc: Vinnie Falco <vinnie.falco_at_[hidden]<mailto:vinnie.falco_at_[hidden]>>; sg19_at_[hidden]<mailto:sg19_at_[hidden]> <sg19_at_[hidden]<mailto: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]<mailto: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]<mailto:SG19_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg19<https://protect.checkpoint.com/v2/r01/___https://lists.isocpp.org/mailman/listinfo.cgi/sg19___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MzIxZDIyY2E4MzhjOGI3ZTRhZGI5ZGQxYWUxYWQwYzM6Nzo2ZGQzOjQ2ODNlNTAzNDkyYmRkMmVlYzI5M2ZiMmRmMmFjYzEwMzRhNTZiMmQ1OWFlNTg0NWQ3Njc2YzM2ZTE5OGQ5YWQ6aDpUOk4>