Proposed resolution:

This wording is relative to N5032.

1. Edit [optional.nullopt], as indicated:

   struct nullopt_t{see below};
   inline constexpr nullopt_t nullopt(unspecified);
   

   -1- […]

   -2- Type `nullopt_t` shalldoes not have a default constructor or an initializer-list constructor, and shall not beis not an aggregate. `nullopt_t` models `copyable` and three_way_comparable<strong_ordering>.

[ Croydon 2026-03-28; Status changed: Immediate → WP. ]

[ Croydon 2026-03-27; Status changed: New → Immediate. ]

[ 2026-03-26; Tim provides wording ]

[ 2026-02-18; Reflector poll. ]

Set priority to 2 after reflector poll.

Discussion whether this needs LEWG approval. Paper P2405, for which the nullopt part received LEWG support, is relevant here.

`std::nullopt_t` currently has no comparison operators. This prevents perfectly reasonable code from working, like `ranges::find(v, nullopt)` where `v` is a vector<optional<T>>, for no good reason.

Additionally, optional<T> has the full set of comparisons. But optional<T> is conceptually a variant<nullopt_t, T>, which wouldn't be comparable... because of `nullopt_t`. Other empty types like tuple<> and `monostate` are also comparable.

Proposed resolution: Add a defaulted member operator<=> to `nullopt_t`.