> 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@lists.isocpp.org> wrote:
On Sun, Oct 4, 2020 at 7:26 PM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals