I have updated the PR and solved the task list. This introduces resizable DataChunk which one can get by a single newChunk call and which is automatically sent after processing. The make API though comes with a drawback, and this is the return by reference, because the instance needs to be stored internally for sending. The return by reference though easily leads to copy if the target variable is not a reference, i.e. a simple forgotten ampersand.

Have studied three options, just to summarize here:

1. forbid the copy constructor

template<> std::vector<char, o2::pmr::polymorphic_allocator<char>>::vector(const std::vector<char, o2::pmr::polymorphic_allocator<char>>&) = delete;

2. make DataChunk a class and forbid copy constructor

class DataChunk : public std::vector<char, o2::pmr::polymorphic_allocator<char>> {
 public:
  DataChunk(const DataChunk&) = delete;
  ...
}

3. Use std::ref to return std::reference_wrapper

None of them is optimal.
Option 1) is probably the most efficient and cleanest solution but it has a drastic global effect, and for this side effect it's most likely out of the question.

Option 2) A bit more cumbersome code, and no option which can be applied to PODs, otherwise quite ok

Option 3) would work very nicely also for the make specializations for PODs because std::reference_wrapper implements the assignment operator. But the discouraging fact is that it also provides a type conversion operator, and this automatic conversion to the underlying type always allows copy. So the forgotten-ampersand mistake is not solved, and option 3 is ruled out.

In the end it's a question of DataAllocator's make interface., and probably we have to live with the drawbacks which come from not returning a pointer. Something which also makes sense. In summary there isn't an optimal solution, but this PR is in line with the current API.

Thank you for the nice write-up.

For 3) if you use auto you do not have the problem you mention, correct?

Anyways, I would go for 2), as 1) is a bit too drastic IMHO, we can always introduce it later on.

Another possibility would be to use a o2::observer_ptr (IIRC the name), but I know you have concerns for that.

To summarise I would go for what I consider the most local change (2) and then expand, once we make up our mind.

Can not access CI results from this PR any more, will open another one