It’s possible that it’s not related to your specific goal, but it is certainly related to the issue that started this topic: https://ziggit.dev/t/what-is-the-best-way-to-handle-unrecoverable-errors-like-outofmemory-in-an-application/
The issue we were discussing is that errors from two different allocators can coalesce into one OOM signal if they’re on the same code path. That’s a confusing signal because if you’re relying on the try functionality, you lose information along the way. It allows for composition of allocators, but that’s a benefit and a cost.
I completely agree - how, why, and where something fails is important information as well - no argument from me here.
Yes - this is an interesting approach that maintains part of the solution. Allocation for special cases can be wrapped and either handled or signal unique information. The issue that @Sze is running into is the compatibility with standard containers since they often expect the allocator interface which has a dedicated error set. So in that case, it’s not easy to swap out in a standard-compliant way. That’s why I’m saying that it may be beneficial to have containers that signal what you need but I wouldn’t expect the standard library to provide those.
What you’re suggesting here is one of the better approaches that can be used to handle the ambiguous-signal issues. Keeping the information distinct or at least on different paths seems to be the most tenable option… but it’s an interesting problem either way.