The Tony Table is a very good addition!
Three comments/questions on the table:

(1) You're missing a `*` in the cast of
`range_value_t<decltype(range)>(nullptr)`.

(2) Is it true that these alternative versions would work both before and
after your proposed change, and in fact work all the way back to C++11
(modulo the use of the `auto& range` C++20ism)?
    auto remove_nulls(auto& range) {
        return std::remove(std::begin(range), std::end(range),
std::nullopt);
    }
    auto after_null_sorted(auto& range) {
        return std::upper_bound(std::begin(range), std::end(range),
nullptr);
    }
(This is just me being curmudgeonly. *Obviously* Ranges is more broken than
STL Classic in this area; your paper proposes to *fix* Ranges in order to
catch it up to STL. Still, this might be a reasonable alternative to list
on the left side of the Tony Table.)

(3) The Tony Table is incomplete, in the sense that you're showing a
function template but not explicitly showing how it would be instantiated.
Are we assuming here that `range` is going to be an object of type
`std::vector<std::optional<int>>`, resp. `std::vector<int*>`? Actually,
why are these templates at all?
I think the "before" should be

    auto remove_nulls(std::vector<std::optional<int>>& v) {
        return std::ranges::remove(v, [](const auto& o) { return o ==
std::nullopt; });
        // or: return std::remove(v.begin(), v.end(), std::nullopt);
    }
    auto after_null_sorted(std::vector<int*>& v) {
        return std::ranges::upper_bound(v, (int*)nullptr);
        // or: return std::upper_bound(v.begin(), v.end(), nullptr);
    }

and the "after" should be

    auto remove_nulls(std::vector<std::optional<int>>& v) {
        return std::ranges::remove(v, std::nullopt);
    }
    auto after_null_sorted(std::vector<int*>& v) {
        return std::ranges::upper_bound(v, nullptr);
    }

And one caveat that is worth mentioning, in order to make sure it is
discussed:
(4) We're adding `nullptr <=> nullptr` for consistency with
`object-ptr-type <=> object-ptr-type`. However, do we also care about
consistency with `function-ptr-type <=> function-ptr-type`? The
well-formedness of that seems to be under debate.
https://reviews.llvm.org/D104680#2839309
*I* don't think this affects the good-idea-ness of your proposal, but
*somebody* might think so.

HTH,
Arthur


On Fri, Jul 9, 2021 at 3:18 PM Justin Bassett via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I agree that LSP is incorrect. That's a symptom of me writing this draft
> while being a bit too tired.
>
> See the updated draft with motivation updated. It also includes a brief
> Tony table.
>
> Thanks,
> Justin
>
> On Fri, Jul 9, 2021 at 12:04 PM Ville Voutilainen via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Fri, 9 Jul 2021 at 21:51, Nevin Liber via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> > That same argument applies to comparing two nullptr_t objects, and yet
>> we can equality compare them.
>>
>> Alright. So nullptr_it has equality, but no ordering, and this
>> proposal gives it ordering. It's a funny ordering tho,
>> since the ordering just tells us that all nullptr_t objects are equal.
>> I'm not sure I see the use of that. Same goes
>> for ordering nullopt objects.
>>
>> That, and practical uses would be useful improvements to the rationale
>> of the proposal. I have no particular
>> predictions of how it'll fare otherwise or with the improved
>> rationale, to me it thus far seems like a harmless but
>> also useless change, so I'm relatively ambivalent about it, although
>> given that, I have a slight bias
>> towards "why bother?" The rationale improvements could change that
>> take. How the rest of the committee
>> see it, I can't tell, and guessing would be fairly futile.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>