How about a size_max() function?

We currently have size_approx() and I understand how that works.

However, I am finding that when I use this queue I frequently want to run some clean up code at the end where I dequeue all the items I added and free them up or do something to them or whatever.

I don't think I can rely on size_approx() as I think it would be plausible that the value wouldn't be guaranteed to be correct if my clean-up code (in thread A) were to run too soon after the last item was added to the queue (in thread B)? I suppose it's unlikely, and I admit I'm not really too sure.

Well I'm finding that to be sure, I have an atomic counter which I increment before I call enqueue(), and decrease after I call dequeue(). You could call this a conservative version of size_approx(), or size_max().

I know then that I can loop until this value is zero, calling try_dequeue() and then I'm definitely going to catch all the items I added.

Is this something that might be added? Or.....as I alluded to above, maybe it's unnecessary?

Start by reviewing the existing size_approx(), enqueue(), dequeue(), and try_dequeue() APIs to understand their guarantees. The issue does not name files or tests; first determine whether a size_max() guarantee is necessary, then define the API behavior and verify it against the queue's concurrent-use semantics.