We had also offline discussions about this topic. The rationale was basically the same as what is stated here, being more flexible with node ids and edge weights.

Also your proposal makes sense. A few (maybe not thorough thoughts):

• The change shifts NetworKit substantially towards a header only library and large header files. This reduces readability, but I am not aware of a technique for avoidance.
• From a design perspective we now have two namespaces/owners of node ids and edge weights. Code independent from the Graph-class currently uses fixed node and edgeweight via Globals.hpp. One way to deal with this would be to also make the datatypes in Globals also templates and provide alias names in order to not break existing code + convenience: node, node32, node16, edgeweight, edgeweight32, ... This would also provide a fallback, whenever a GraphType is not available.
• Is there a way to avoid to add using NodeType = ... and using EdgeWeightType = ... at the beginning of the algorithms? It is just convenience, however this will likely lead to different parameter names in different classes, reducing readability further.

Likely, other modules/classes like GraphTools, generators or Aux need also be converted to templates in the end - however with the proposed solution this can be done in reasonable chunks.

Not an assigned reviewer, but I wanted to share a quick thought on the topic:
One way to keep the API clear while staying header-only is to split each templated class into:

• A .hpp file containing only the declarations, docs and the using Graph = … alias.
• A matching .inl (or .tpp) file with all of the inline/template implementations.
• Then at the bottom of each X.hpp we simply include the corresponding #include "X.inl"

That way:

• Readers see a concise interface first, without wading through implementation details.
• Retains header-only compilation (no extra .cpp needed).
• IDEs and doxygen can be pointed just at the .hpp for cleaner navigation.

Thank you both for your feedback.

The change shifts NetworKit substantially towards a header only library and large header files. This reduces readability, but I am not aware of a technique for avoidance.

That's right. For readability, we could adopt the suggestions from @Schwarf, but we can't avoid other issues like longer compilation time.

Code independent from the Graph-class currently uses fixed node and edgeweight via Globals.hpp. One way to deal with this would be to also make the datatypes in Globals also templates and provide alias names in order to not break existing code.

I think that an easier solution is to template that code and add default template parameters to minimize changes in non-template algorithms using it. For example, BucketPQ.hpp defines an <int64_t, uint64_t> priority queue. We could replace it with:

// BucketPQ.hpp
template <class KeyType = int64_t, class ValueType = uint64_t>
class BucketPQ : public PrioQueue<KeyType, ValueType> {
    static_assert(std::is_signed<KeyType>() && std::is_integral<KeyType>());
   // ...
};

// SomeAlgo.hpp
// Instead of `BucketPQ prioQ;`
BucketPQ<> prioQ;

And then we gradually stop using the types declared in Globals.hpp as we template the classes using it.

Let me know if what you are proposing is simper than this, I might have misinterpreted it.

Is there a way to avoid to add using NodeType = ... and using EdgeWeightType = ... at the beginning of the algorithms?

Yes, we can do something similar as done with NodeIterators.hpp. The disadvantage is that doing so we have to specify the template arguments each time for GraphType as well:

template <template <class, class> class GraphType, class NodeType, class EdgeWeightType>
class FloydWarshall : public Algorithm {
public:
  // Before:
  // FloydWarshall(const GraphType &G);
  // Now it becomes:
  FloydWarshall(const GraphType<NodeType, EdgeWeightType> &G);
};

// Before:
// template <class GraphType>
// void FloydWarshall<GraphType>::run() {}
// Now it becomes:
template <template <class, class> class GraphType, class NodeType, class EdgeWeightType>
void FloydWarshall<GraphType<NodeType, EdgeWeightType>>::run() {}

To me this looks too cluttered. Adding the using NodeType = ... and using EdgeWeightType = ... at the beginning is redundant, but it significantly simplifies the code. I'm not aware of other solutions.

My question is how do we move from here? If we agree to proceed with this change, I think that we should clarify:

• How we migrate the C++ code: how we name the template parameters (e.g., we could shorten them as NodeT and EdgeWeightT), whether we prefer having the using NodeType = ... and using EdgeWeightType = ... or the more verbose template <template <class, class> class GraphType, class NodeType, class EdgeWeightType> or others if available, etc.
• Prepare a migration plan: after Graph, which algorithms/functions do we want to migrate first? Do we also want to migrate their Cython counterparts? For example, instead of a 64-bit graph, we could expose to the Cython code only a 32-bit graph.

Let me know what you think.