A good use case for such methods would be std::optional<T&>, if it is
internally containing a T*, then nullptr can represent disengaged since a
reference can't be nullptr

On Mon, Jul 22, 2024, 18:09 Heckerpowered via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, 22 Jul 2024 at 17:23, someone with garbled name via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> Maybe we can go further. Here is my solution.
> We add a template struct in namespace std.
>
> template<class T>
> struct invalid_state; //No definition
>
> …
>
> Introducing an invalid_state template in namespace std is good, but I
> think it’s inappropriate compare to the element’s binary to determine
> whether a std::optional has a value. Sometimes we need to determine whether
> a std::optional is empty with multiple members, and the memory layout of
> the members may be discontinuous.
>
> In addition, there’s another problem, it may be a little troublesome to
> obtain the binary of a invalid value and hard-code it into the source, and
> it has poor semantics, may be a series of 0xff in the example is easy to
> understand, but I don’t think it’ll always be that way. All in all, I think
> the implementation in the example is somewhat limited.
>
> Instead of comparing the binary of members, I think it would be better to
> use unary predicate, for example:
>
> '
> template<typename T>
> struct invalid_state; // in namespace std
>
> template<>
> struct invalid_state<my_class>
> {
> bool operator()(const my_class& my_object) no except {
> return my_object.member == /* a invalid value */;
> }
> };
> '
> The new implementation can do anything the previous implementation can do,
> and has better semantic. Such as a vector, comparing its size with
> std::numeric_limits<std::size_t>::max() is absolutely better than a series
> of 0xff, and people, and it’s difficult for humans to determine how many
> 0xff(s) are there in a series of 0xff quickly, so better semantics can help
> reduce potential problems.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>