Modern namespace: boost::graph::

[Becheler]

Story

BGL's types and free functions live directly in boost:: with no scoping. Types like adjacency_list, compressed_sparse_row, filtered_graph. Free functions like vertices(), edges(), source(), target(), get(), put(). These are generic names that can interact unexpectedly with other libraries. Free functions are particularly tricky because of ADL: a call to get() or vertices() anywhere near a BGL graph can silently resolve to the BGL version.

At the same time, every improvement proposal runs into backward compatibility: adding an allocator parameter, cleaning up the property map API, introducing range-based traversal all require touching interfaces that production code depends on today. addy90 needed a different adjacency_list and could not get one without leaving BGL entirely.

One idea raised in the discussion:

boost::adjacency_list<vecS, vecS>;                    // unchanged
boost::graph::adjacency_list<vecS, vecS, ..., Alloc>; // new, modern

Boost.Spirit has done this across multiple generations: Spirit Classic, then boost::spirit::qi::, then boost::spirit::x3:: all coexisting with the previous one under its own sub-namespace.

Dream solution

• BGL can evolve freely without breaking existing users.
• Generic names are scoped cleanly.
• A clear policy exists for what is legacy and what is modern, and users know where to look.

Starting point

Arnaud's namespace comment in discussion #466
Boost.Filesystem v3 namespace migration
DmitriBogdanov's comment in discussion #466

Intermediary objective (45 min)

Read the starting points and discuss openly. Write down your findings on:

1. Is namespace pollution actually a problem in practice? Can you find or construct a concrete example where it causes a real issue?
2. What are the risks of introducing a parallel namespace? What could go wrong for users, for documentation, for maintenance?
3. Are there other approaches that would solve the same problems without a new namespace?
4. If a boost::graph:: namespace were introduced, what would the migration story look like for existing users?
5. Is this the right moment to do this, or should it wait until other pieces (allocators, concepts, ranges) are further along?