Consistency with std::unique_ptr

[matt77hias]

Is your feature request related to a problem? Please describe.
Why does unique_resource not provide a operator bool, operator ==, operator <=>, and std::hash specialization if the underlying handle type supports these (similar to how operator * and operator -> are currently handled for pointer-like handle types)?

Providing these operators (with concepts/SFINAE depending on the underlying handle type), would make unique_resource for handles mores consistent to unique_ptr for pointers. unique_resource and raw handles then only differ with regard to ownership, similar to unique_pointer and raw pointers, where the former owns the (memory) resource and the latter merely provides a view (or capability to view it).

(Un)ordered containers that own the resources would also benefit from this, as they would not require any custom comparators. Unordered containers would also not require any custom hash function.

[PeterSommerlad]

Thank you for the feature request.

It might be time to resurrect my unique_resource proposal for C++23 (without the scope guards, which are a design smell anyway.)

explicit operator bool() const noexcept is a no brainer, it is just nobody in LEWG asked for it at the time.

Equality, one can argue to be trivial to provide as well. One question, does the deleter object also participate in it, what if that one does not have equality, but has state? Even when the unique_resource is detached?

However, relational operators are much harder than with unique_ptr, because one needs to consider how a detached unique_resource relates to all the filled unique_resource objects of the same type. Should it be less than all those? This can break assumptions by users of the resource type. Should it be neither less nor greater? This leads to the NaN problem of a set<double>. Also with pointers we have at least a total order defined by std::less and a detached unique_ptr is equivalent to nullptr. The possibility that there is a relational operator (except <=>) does not guarantee any specific property of such a comparison. If you can provide me with insights there, especially since I do not have yet practical experience with spaceship.

It would be easy, if unique_resource really deals only with trivial handle types, but that was removed from my initial design by LEWG and Eric Niebler.

[matt77hias]

One question, does the deleter object also participate in it, what if that one does not have equality, but has state?

That is actually a very good point, as it is possible to have distinct resource managers providing access to the same type of resources. And personally, I prefer storing a pointer to the resource manager inside the deleter instead of inside the resource (e.g., example), which would be problematic for equality, logical comparisons and hashing if resources of different resources managers are involved into the equation.

So unlike memory resources which are globally unique (independent of distinct memory allocators involved or not), it seems like unique_resource should consider its deleter unlike unique_ptr.

But this indeed makes it even more complex for detached resources. Should the deleter be considered at all in that case? What is the difference between two detached unique_resources with distinct deleters?

And hashing support would be complex as well, as combining separate hashes into one hash isn't part of the standard library.

A possible solution would be adding additional template arguments to unique_resource to let the user decide on all of these operations. (That feels a bit overkill, though :-) )

P.S.: it would be really great to have this in C++23 instead of LTFS (as Microsoft's STL does not have it) as it is super light-weight, non-intrusive, can store by value, does not involve dynamic memory allocations or virtual inheritance.

[gotnone]

Is is possible that the "deducing this" feature of C++23 could allow the user to mixin various operators to their own customized unique_resource? I haven't played with this, because only MSVC has support.