[cfe-dev] [libcxx] Improvement to the implementation status page

[Robert Underwood via cfe-dev]

Marshall,

A few thoughts:


On Mon, Aug 3, 2020 at 9:36 AM Marshall Clow <mclow.lists at gmail.com> wrote:
>
> On Aug 3, 2020, at 5:15 AM, Robert Underwood via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> >
> > To whom it may concern,
> >
> > I wasn't sure if this is more of a RFC/change proposal or a
> > documentation bug, so I am sending this here first before filing a bug
> > if required.
> >
> > As an end-user, I find the [libc++ status][libcxx_status] page
> > somewhat misleading/hard to follow, and I suspect I am not the only
> > one (more on that  in a minute).
>
> I understand, but that’s not the purpose of that page.
> That page is there to track the implementation of every change made to the standard that affects libc++.
> [ i.e, it’s there for the implementors, primarily, and secondarily users. ]
>
> > I wanted to know if libc++
> > implements std::span and the <span> header completely for C++20.
>
> The correct check is to attempt to include #include <span>.
> If that succeeds, then check the value of `__cpp_lib_span`.

Some additional context, I am implementing a poly-fill using libc++
for select c++20 library features for c++11 compilers (including some
proprietary compilers) required for some machines I use.  I have to
work with old existing standard library versions (sometimes libc++
sometimes something else), and when I detect that a features doesn't
exist or doesn't work, I fall back to a standalone version I write
based on libc++ with in some cases some additional changes to get it
to compile under c++11.  However when a feature exists and works, I
use the native version because it often has some performance
optimizations for the specific machine/"blessed" compiler.

I don't have access to #__has_include from c++17, but I can use
features like autotools and cmake's header detection to check for
existence.  Additionally, some of the earlier standard libraries that
I work with are missing some of the version macros even for supported
features because the macros weren't standardized until later.  Again
something I can work around with compiling test programs, but my point
is your proposed solution isn't perfect here.  However when I use test
programs, I either have to spend a while writing a test that exercises
all functionality added in a version or I risk false positives by just
checking for a few constructors and functions I use for the moment.

>
> Each significant revision of the span specification *should be* marked with a change to the value of that macro.
> As a bonus, this is a cross-library way of checking.
>
>
> > So I
> > look at the [status page][libcxx_status], I am presented with a list
> > of papers that were accepted and at which committee meeting the paper
> > was approved to be merged into the standard. This is all fine and
> > useful, but it obscures the fact that <span> for C++20 is actually
> > implemented over several separate papers: P0122R7, P1085R2, P1024R3,
> > P1394, P1872, P1976, P2116, and possibly others that don't have span
> > in the title; Something that could easily be missed if just reading
> > paper titles, lazy, or if one was less familiar with the committee
> > process or just being lazy.
>
> Right. And if that status page just said “Span: Implemented”
> then it would be easy for it to be wrong - or worse, for us to believe that we had implemented all the bits of span, without noticing that we had missed (say) P2116.

I wasn't sure if I was clear, so please forgive me if I wasn't.  I
don't want the page entirely rewritten.  I think it serves a useful
purpose as is.

I'm asking if an additional column could be added listing the affected
headers and some small javascript that allows you to sort and filter
by column with the default view being the current view of the page.

>
> > Now why do I think others find this misleading?  If you look at the
> > [cppreference[cppreference] conformance table, it lists that libc++
> > has had span support since version 7.0 which corresponds to the entry
> > for "<span>" in the table from the [status page][libcxx_status], but
> > this isn't true because in reality it's missing P1394.  I'm guessing
> > whoever made the changes to the cppreference page made the same
> > mistake that I did.
> >
> > It would be very useful/helpful to be able to order the status page by
> > the header/module unit affected.  I.E. all the papers that affect
> > <any>, then all that effect <barrier>, then all that effect <bit>,
> > etc...  This means that a paper such as P2116 could be listed under
> > <span> and <tuple> because it removes std::tuple_size<> support for
> > std::span<>.  I could understand it also being listed under <array>,
> > <utility>, and <ranges> as these headers are also affected by the
> > change since they also would expose the specialization of tuple_size.
> > A section could be added for "all" for completely cross cutting
> > standard library changes such as paper P1424 related to feature macros
> > for constexpr support.
> >
> > I believe these changes would also help implementers to ensure that
> > all aspects of a standard library specific feature have been
> > implemented.  Please let me know what you all think?
>
> I think that it would lead to the opposite result.

If that is your opinion, I respect your decision.  Thank you for all
the work you put into LLVM, Clang, and libc++!

Respectfully,
Robert Underwood

>
> — Marshall
>