The paper list in the Revisions section that the allocator parameter has been removed from the algorithm interface. This is insufficient. The paper should provide the discussion on what options for dealing with memory management were considered and why the alternatives have been rejected. This will help LEWG make their decision.
I can see the situation, where I need to conduct three similar algorithms on the same graph consecutively and I could reuse the same memory fragment. A natural interface for me would be to pass the buffer as an input argument. I could achieve the same thing with an allocator interface (I would disguise my buffer as an allocator). The current solution prevents me from doing such optimizations.
I am not saying, that we ultimately need to have such optimizations. But at minimum, it requires an analysis in the paper.
The paper list in the Revisions section that the allocator parameter has been removed from the algorithm interface. This is insufficient. The paper should provide the discussion on what options for dealing with memory management were considered and why the alternatives have been rejected. This will help LEWG make their decision.
I can see the situation, where I need to conduct three similar algorithms on the same graph consecutively and I could reuse the same memory fragment. A natural interface for me would be to pass the buffer as an input argument. I could achieve the same thing with an allocator interface (I would disguise my buffer as an allocator). The current solution prevents me from doing such optimizations.
I am not saying, that we ultimately need to have such optimizations. But at minimum, it requires an analysis in the paper.