Ensure that our memory pools can implicitly convert to a resource_ref

[miscco]

We want to pass them to APIs that take only a resource_ref.

However, because those are not copyable we would need to convert them to a memory_pool_ref first.

However, that also does not work, because the constructor for resource_ref does not accept a prvalue.

To alleviate that create a conversion operator that does the right thing.

[pciolkosz]

However, that also does not work, because the constructor for resource_ref does not accept a prvalue.

Would it make sense to return a X_memory_pool_ref& from as_ref() to change this? It most likely has its own set of issues as any function returning references. But the proposed change has a bit of a surprising effect for this sequence:

device_memory_pool pool{dev0};
resource_ref ref = pool;
any_resource res = ref;

We support turning resource_ref into any_resource by creating a copy of the resource. Because pool -> resource_ref conversion also downgraded the resource from owning to non-owning, when you create any_resource you end up having only the non-owning device_memory_pool_ref wrapped inside. I think I would prefer there to be an explicit as_ref() call somewhere in this sequence, so the user explicitly opts-in into this ownership change of the resource. It's not a strong concern though and if we think this is still the best way to make resource_ref more compatible with the memory pools I would be fine with the proposed changes

[pciolkosz]

@miscco We discussed this on the working group meeting today and a suggestion from @ericniebler was to move the conversion operator from X_memory_pool to X_memory_pool_ref, so that we can keep the conversion to X_memory_pool_ref explicit with .as_ref(), but it should now work as an argument to a function expecting a resource_ref when user call .as_ref() on it. Basically solves the prvalue problem from the PR description

[miscco]

@pciolkosz I tried your approach but that is not possible without an intermediary.

The issue is that the resource_ref stores a pointer to the temporary created within as_ref so this will just dangle

[miscco]

@pciolkosz I believe I found an elegant solution to the issue at hand.

The underlying problem is that the construction to a meow_pool_ref creates a temporary.

However, a relatively simple solution is to just downcast to the meow_pool_ref in as_ref() and return by reference

There is no functional difference to the current constructor call, because that is what we actually store and the reference allows us to directly convert into a resource_ref

I believe that gives us the best of both worlds

[github-actions]

🥳 CI Workflow Results

🟩 Finished in 1h 21m: Pass: 100%/99 | Total: 1d 02h | Max: 55m 29s | Hits: 97%/251185

See results here.