For example, linked lists. Generally, it’s harder to experiment with algorithms because not nearly as much is available.
However, the biggest pain is that igraph’s data structures can’t be flexibly templated on the element type. What if I want a set that holds not numbers but pairs of numbers? Something could be done with pointers, but it’s not sufficient to allow pointers. Some data structures need certain operations such as <, >, == comparisons or hashing. Providing these through a callback is both inconvenient and is likely a major performance hit compared to what C++ offers through inline functions and templates.
In the end, the system just can’t be made nearly as convenient as C++ (and it’s likely slower too).
This was a lot easier to write in C++, not only because it currently uses data structures that igraph doesn’t have, but also because it was much easier to change things and experiment while developing it: https://github.com/igraph/igraph/blob/master/src/degree_sequence.cpp (But frankly, I don’t remember why I ended up with linked lists.)
Anyway, back to array3: For some time now I wanted a function that converts binary images to graphs. This is very useful with spatial networks and microscopy data, some of which is 3D. I am not 100% happy with any of the tools that exist for this. It would be a good addition and it could be done for 3D images as well.
When, if ever, I get to it, I don’t know. My point is that stripping out pieces of code that might find use in the future should not be done lightly. “Clean codebase” is to some extent subjective. We need to know what tangible benefits we are getting. Don’t want to maintain it? Don’t actually have to right now. Worried that people will use it and it might have bugs? Remove it from the docs.