Michael suggested I list the issues identified by Oliver, which I've identified below.

In addition to the items listed, we also know we need to refine the definition of the edgelist concepts.

Oliver indicated there may be more things, so this will likely be an incremental process to refine the proposal.

Since the original comments, P1709 has been split into multiple papers numbered P3126..P3131 consecutively. They follow the same structure as P1709 with the chapters being made individual papers.

Open Issues

  1. "[P1709] has lots of details which I think to be irrelevant"
     * Need clarification.
  2. "Very hard to follow" mentioned 2x.
     * It's presented as a series of layers in the library. Need clarification on what makes it difficult.
  3. My comment about the structure of the paper changing was a reference to previous comparisons with boost::graph. I'm sure these were in an earlier version, or am I misremembering?
     * We never had any comparisons to BGL.
     * Andrew is planning on adding a new paper to compare graph-v2 with BGL.
  4. "We need to add a mathematical perspective to the paper."
     * P3127 was created from the Background chapter in P1709 and was intended for the mathematical background.
     * Andrew is planning extending P3127 to include a more rigorous mathematical description. We would like to have an independent review when it's ready.
  5. "there needs to be a proper discussion about whether the paper's definition of graph is what some authors call a multigraph and whether it does/does not include loops."
     * The current version of P3128 Algorithms has a summary table for each algorithm that includes Complexity, Directed?, Multi-edge?, Cycles?, Self-loops?, and Throws?. We still need to make a pass through the algorithms to assure the values are correct.
  6. The electrical circuit example has issues in P3127, section 6.1.
     * Andrew has acknowledged this and will replace it with a better example.
  7. A concern is that the DFS and BFS functionality isn't flexible enough, especially when compared to boost::graph's visitors.
     * We've agreed to provide more flexible versions of BFS & DFS.
     * Phil is researching coroutines as an alternative.
                                                               i. Oliver likes the examples I've shown but has also pointed out coroutines can't be constexpr. Because of that, he would also like visitors included.
                                                             ii. Guy said that coroutines might raise concerns as a "novel" approach by LEWG.
                                                           iii. There are open questions about performance differences between the use of coroutines vs. visitors we will be investigating.

  1. "I'm not convinced by the load api."
     * Phil: I'm not either. I'll re-examine this to see if I can expand the list of constructors in compressed_graph so the load functions can be removed.

Resolved Issues

  1. "build on mdspan and try to standardize (or at least understand) what might reasonably be called an unstructured span"
     * Assumes vertices are in a random-access range and prevents the use of bi-directed ranges like std::map, which could be used for sparse vertex ids. The existing design should be able to adept easily to mdspan, so there's no reason to pursue this.