On Mon, 22 Jul 2024 at 17:52, Giuseppe D'Angelo via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> Being a "null object" (whatever that means) doesn't mean that such a
> null object can be used as the representation of a non-engaged optional.
> A non-engaged optional means there's NO object. A null object means that
> there is an object. This is a complete non-sequitur.

Indeed. Furthermore, for example, you can have code that processes the
optional, checks that it's engaged,
and then hands the result of *opt to some other code for filling in
the value, perhaps by simple assignment. If you don't know the
difference between a disengaged optional and an optional holding a
'null' value, then you can no longer
do that.

And there's of course the rather canonical database field example,
where there is a difference between a field
not being set at all, and a field being set to a null string. Or null
whatever, but nevertheless set to some value, possibly null.