index_adjacency_list and other concepts

[akrzemi1]

I would like to start the discussion on changing the concepts a bit. The current one (index_adjacency_list) is buggy and somewhat unfriendly to users. But rather than patching individual bugs, I would go with some principal approach.

The things that I consider in need of fixing:

One. If a concept is defined in terms of CPOs, the defining CPOs require a more clear specification. We have to know which of the many CPOs are crucial for the definition of the concepts, and which are just optimization.

Two. Too many concepts.

Three. A hole in index_adjacency_list. It requires that target_id returns something copyable (the copyable requirement is concealed inside the CPO), but nothing more. Whereas view bfs_base apparently requires that the result of target_id is convertible to vertex_id_t<G> (see here). As a result, I can customize my graph, so that it satisfies concept index_adjacency_list, but any algorithm using my type fails to compile (see bad_type_that_satisfies_the_concept.cpp.txt).

Four. Unnecessary two concepts: one for accessing vertices by index, the other for looking up vertices as if in a map. They can be merged by providing another CPO: get_vertex(g, vid) that will perform the look-up in a way most appropriate for the user graph.

[akrzemi1]

A couple of thoughts regarding the non-index adjacency list, that is, the situation where vertex_id_t<G> is nothing close to being std::integral.

One. I can see that there already is a CPO find_vertex(g, uid), it is already sufficient to provide (a) a random access to the vertex list by id, in case ids are contiguous integral numbers, and (b) map-like lookup, for other types of ids. You do not need the random access range to vertices. You only need a forward iteration over vertices, in case you need to initialize some data initially, and then find_vertex(g, uid) is sufficient for random access.

Two. Is the case where vertex_id_t<G> is not std::integral real and worth abstracting for? Maybe it isn't? And then the whole design becomes way simpler. But if it is, servicing non-integral ids requires rethinking the interface for algorithms such as Dijkstra's multi-source shortest paths. Currently, one of its arguments is distances which is a random_access_range. This is not enough for non-integral indexes. And now we may also need a CPO for distances.

[akrzemi1]

On defining concepts in terms of CPOs.

One. When we see a constraint like

requires(G&& g, vertex_id_t<G> uid) {
  { edges(g, uid) } -> forward_range;
}

it is not clear if the constraint is on the CPO, or the function (the customization) provided by the author of G. Note that the customization points in this library change and modify user customizations.

Two. The implied requirements on CPOs -- in the form of using types like vertex_id_t<G> -- in the constraints are too tricky, and they prevent the compiler from generating good error messages. Instead, the requirements on the validity of customization points should be explicitly mentioned.

[akrzemi1]

it is not clear if the constraint is on the CPO, or the function (the customization) provided by the author of G.

Sorry, it is my misunderstanding of the name lookup rules. Having found a function object precludes any argument-dependent look-up of functions and function templates. The names must be CPOs.

[akrzemi1]

I think I can now better articulate my observation. I believe that "random access range of forward ranges" may not be the best way to describe the adjacency list. I think a more accurate model would be: a forward range (of vertices) of forward ranges (of edges) with the ability to perform the look-up back into the outer collection of vertices.

You need the forward iteration of vertices to count them or to apply something for each vertex (like initialization). And then, once you have found the id of the target vertex, to look it up in the collection of vertices.

A random-access range happens to provide both these functions (forward iteration and efficient lookup), but in general you do not need the full power of a random-accees range.