On Fri, 9 Jul 2021 at 17:36, Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
> The paper's motivation is vague, without any practical examples where
> such comparisons would be useful, let alone
> important to have.

Furthermore, as presented, the paper's motivation seems incorrect to
me. For a nullopt to be Liskov-substitutable
for an optional, it would need to have the full API of optional, and
just adding comparisons isn't sufficient for that.
The design intent was never for nullopt to be a Liskov-substitutable
stand-in for an optional, it's just a tag type
that optional is constructible and assignable from. The aforementioned
vagueness problem is that I find it
hard to imagine a programmer either accidentally or deliberately
running into problems with nullopt, because
you would either need to concoct situations where you create two
nullopts and just try to treat them as optionals,
or somehow manage to get into that situation via some hypothetical generic code.

These tag types are not for general programming, they're for use as
constructor arguments. Don't pass them
into your hypothetical generic code and expect them to LSP to some
other type (which type? There's an open
set of such types.).