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

Robert Underwood via cfe-dev cfe-dev at lists.llvm.org
Mon Aug 3 05:15:38 PDT 2020

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 wanted to know if libc++
implements std::span and the <span> header completely for C++20.  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.

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?

Robert Underwood

[libcxx_status]: https://libcxx.llvm.org/cxx2a_status.html
[cppreference]: https://en.cppreference.com/w/cpp/compiler_support#cpp2b

More information about the cfe-dev mailing list