> Sure it does. optional<void> still has two states: engaged nothing and
disengaged. It may seem like a weird spelling of bool, but it's a perfectly
meaningful type and fills a hole in the type system.

Exactly. And also. It is a little paradigm shift requested to sort this
out, where std::optional is the first std lib type already implementing the
age-old concept of occupancy state: "empty" or "has value". Database theory
and fields. Field always exist, but it can be empty or not. And if it is
not empty just then we ask if the value in there is null or void or has
some value meaningull for the operational context. optional<void> has a lot
of sense: it covers a valid context of a function return in this use case.

DBJ

On Mon, 5 Oct 2020 at 02:46, Barry Revzin via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, Oct 4, 2020 at 7:26 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> And it doesn't make sense for `optional` to allow any kind of "no
>> value" type. You can't have a NothingOrNothing type ;)
>>
>
> Sure it does. optional<void> still has two states: engaged nothing and
> disengaged. It may seem like a weird spelling of bool, but it's a perfectly
> meaningful type and fills a hole in the type system.
>
> For instance, we could consider adding a member function ok() to
> expected<T, E> that returns an optional<T> (Rust's Result has such a
> function, for instance). Perhaps you have some generic code that might want
> to drop the error for whatever reason. The inability to define such a
> function for void is *yet another *really annoying scenario where void
> has to be treated specially. The same holds for any generic operation on an
> optional, really.
>
> Barry
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>