On 10/07/2021 09.18, Justin Bassett via Std-Proposals wrote:
> I attempted to address these issues in the attached updated draft. It adds many more diffs to the Tony Table, talks about N2478, briefly discusses the odd nature of requiring equality_comparable<U> for equality_comparable_with<T, U>, and includes a few minor changes (adding SG9, uses a hidden friend for the defaulted operator<=>, borrows the wording prior to N2478 for nullptr comparisons).
>
> On the Tony Tables: it turns out that without the templates, many of the examples are trivially fixed by converting nullopt -> std::optional<int>() or nullptr -> std::shared_ptr<int>(). With templates, suddenly the information of precisely what optional or what smart_ptr was used becomes hidden, so we have to spend effort to recover that information. So the templates in fact show some cases with a bigger impact. However, even without the templates, it can turn out to be more readable to use the nullfoo variants instead of default constructed types.

What does "alternative is enabled" mean?

In your Tony Table for remove_nulls(nullopt), you assert
that you have a range of optionals. The lambda passed to
ranges::remove_if can thus be cleanly replaced by
ranges::range_value_t<R>() (which ends up as optional<T>()).
Using this formulation makes the algorithm actually apply
for both smart pointer and optional uses, because the
funny nullopt vs. nullptr in the body has been eliminated.

In short, I don't feel the Tony Tables adequately represent
the best practice in formulating those algorithms, either
"before" or "after". Given that, the "odd" behavior of
nullptr and nullopt is maybe actually good, because it forces
you to write better code for these generic situations.

Please rebase onto the newest working draft, https://wg21.link/std

(This might just be an exercise in updating the references.)

Thanks,
Jens