[libcxx-commits] [PATCH] D136657: [libc++][ranges][NFC] Revamp the Ranges status page

Konstantin Varlamov via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Oct 25 20:36:47 PDT 2022


var-const added inline comments.


================
Comment at: libcxx/docs/Status/Cxx20Issues.csv:100
 "`2697 <https://wg21.link/LWG2697>`__","[concurr.ts] Behavior of ``future/shared_future``\  unwrapping constructor when given an invalid ``future``\ ","San Diego","",""
 "`2797 <https://wg21.link/LWG2797>`__","Trait precondition violations","San Diego","Resolved by 1285R0",""
 "`2936 <https://wg21.link/LWG2936>`__","Path comparison is defined in terms of the generic format","San Diego","|Complete|",""
----------------
h-vetinari wrote:
> It might also be worth to linkify all those papers (as done elsewhere)
Agreed, but I'd rather do it in a separate patch and keep this focused on Ranges. (Or feel free to send in the patch if you'd like)


================
Comment at: libcxx/docs/Status/Cxx20Issues.csv:206
 "`3238 <https://wg21.link/LWG3238>`__","Insufficiently-defined behavior of ``std::function``\  deduction guides","Prague","",""
 "`3242 <https://wg21.link/LWG3242>`__","``std::format``\ : missing rules for ``arg-id``\  in ``width``\  and ``precision``\ ","Prague","|Complete|","Clang 14","|format|"
 "`3243 <https://wg21.link/LWG3243>`__","``std::format``\  and negative zeroes","Prague","|Complete|","14.0","|format|"
----------------
h-vetinari wrote:
> Always been mildly bothered by this inconsistency.
Same -- agreed this should be fixed, but I'd rather keep this patch smaller. Would you like to do a patch with the fixes you mentioned? I can help you with generating the docs to check the change locally.


================
Comment at: libcxx/docs/Status/Cxx2bIssues.csv:37
 "`3448 <https://wg21.link/LWG3448>`__","``transform_view``'s ``sentinel<false>`` not comparable with ``iterator<true>``","November 2020","","","|ranges|"
 "`3449 <https://wg21.link/LWG3449>`__","``take_view`` and ``take_while_view``'s ``sentinel<false>`` not comparable with their ``const iterator``","November 2020","Complete","16.0","|ranges|"
 "`3453 <https://wg21.link/LWG3453>`__","Generic code cannot call ``ranges::advance(i, s)``","November 2020","|Nothing To Do|","","|ranges|"
----------------
h-vetinari wrote:
> 
Thanks!


================
Comment at: libcxx/docs/Status/Cxx2bIssues.csv:76
 `3521 <https://wg21.link/LWG3521>`__,"Overly strict requirements on ``qsort`` and ``bsearch``","June 2021","|Nothing To Do|",""
-`3522 <https://wg21.link/LWG3522>`__,"Missing requirement on ``InputIterator`` template parameter for ``priority_queue`` constructors","June 2021","|Complete|","14.0","|ranges|"
+`3522 <https://wg21.link/LWG3522>`__,"Missing requirement on ``InputIterator`` template parameter for ``priority_queue`` constructors","June 2021","|Complete|","14.0"
 `3523 <https://wg21.link/LWG3523>`__,"``iota_view::sentinel`` is not always ``iota_view``'s sentinel","June 2021","","","|ranges|"
----------------
h-vetinari wrote:
> Missing ,"" at the end (might work without it, but still cleaner to have right number of columns)
I'm not sure -- the existing formatting seems to always have an empty column for the status row and the first released version raw, but not for the label row. I followed that for consistency, but I presume either works.


================
Comment at: libcxx/docs/Status/Cxx2bPapers.csv:65
+"`P2278R4 <https://wg21.link/P2278R4>`__","LWG","``cbegin`` should always return a constant iterator","July 2022","","","|ranges|"
+"`P2286R8 <https://wg21.link/P2286R8>`__","LWG","Formatting Ranges","July 2022","","","|format| |ranges|"
 "`P2291R3 <https://wg21.link/P2291R3>`__","LWG","Add Constexpr Modifiers to Functions ``to_chars`` and ``from_chars`` for Integral Types in ``<charconv>`` Header","July 2022","|Complete|","16.0"
----------------
Mordante wrote:
> This will be a merge conflict, the status is partial https://libcxx.llvm.org/Status/Cxx2b.html
Thanks! Should I add you as an assignee on this in the `RangesMajorFeatures.csv` list? (it's primarily to make sure we don't accidentally duplicate work)


================
Comment at: libcxx/docs/Status/RangesIssues.csv:1
-"Number","Name","Status","First released version"
-`P0896R4 <https://wg21.link/P0896R4>`__,<ranges>,|Complete|,15.0
-`P1035R7 <https://wg21.link/P1035R7>`__,Input Range Adaptors,,
-`P1207R4 <https://wg21.link/P1207R4>`__,Movability Of Single-Pass Iterators,|Complete|,15.0
-`P1243R4 <https://wg21.link/P1243R4>`__,Rangify New Algorithms,|Complete|,15.0
-`P1248R1 <https://wg21.link/P1248R1>`__,Fixing Relations,|Complete|,13.0
-`P1252R2 <https://wg21.link/P1252R2>`__,Ranges Design Cleanup,|Complete|,15.0
-`P1391R4 <https://wg21.link/P1391R4>`__,Range Constructor For string_view,|Complete|,14.0
-`P1456R1 <https://wg21.link/P1456R1>`__,Move-Only Views,|Complete|,15.0
-`P1474R1 <https://wg21.link/P1474R1>`__,Helpful Pointers For contiguous_iterator,|Complete|,15.0
-`P1522R1 <https://wg21.link/P1522R1>`__,Iterator Difference Type And Integer Overflow,|Complete|,15.0
-`P1523R1 <https://wg21.link/P1523R1>`__,Views And Size Types,|Complete|,15.0
-`P1638R1 <https://wg21.link/P1638R1>`__,basic_istream_view::iterator Should Not Be Copyable,,
-`P1716R3 <https://wg21.link/P1716R3>`__,Range Comparison Algorithms Are Over-Constrained,|Complete|,15.0
-`P1739R4 <https://wg21.link/P1739R4>`__,Avoiding Template Bloat For Ranges,|Complete|,15.0
-`P1862R1 <https://wg21.link/P1862R1>`__,Range Adaptors For Non-Copyable Iterators,,
-`P1870R1 <https://wg21.link/P1870R1>`__,forwarding-range<T> is too subtle,|Complete|,15.0
-`P1871R1 <https://wg21.link/P1871R1>`__,Concept traits should be named after concepts,|Complete|,14.0
-`P1878R1 <https://wg21.link/P1878R1>`__,Constraining Readable Types,|Complete|,15.0
-`P1970R2 <https://wg21.link/P1970R2>`__,Consistency for size() functions: Add ranges::ssize,|Complete|,15.0
-`P1983R0 <https://wg21.link/P1983R0>`__,"Wording for GB301, US296, US292, US291, and US283",|Complete|,15.0
-`P1994R1 <https://wg21.link/P1994R1>`__,elements_view Needs Its Own sentinel,,
-`P2091R0 <https://wg21.link/P2091R0>`__,Fixing Issues With Range Access CPOs,|Complete|,15.0
-`P2106R0 <https://wg21.link/P2106R0>`__,Alternative wording for GB315 and GB316,|Complete|,15.0
-
-`P2325R3 <https://wg21.link/P2325R3>`__,Views should not be required to be default constructible ,,
-`P2328R1 <https://wg21.link/P2328R1>`__,join_view should join all views of ranges,|Complete|,14.0
-`P2210R2 <https://wg21.link/P2210R2>`__,Superior String Splitting,,
-`P2281R1 <https://wg21.link/P2281R1>`__,Clarifying range adaptor objects,|Complete|,14.0
-`P2367R0 <https://wg21.link/P2367R0>`__,Remove misuses of list-initialization from Clause 24,,
-
-`P2415 <https://wg21.link/P2415>`__,"What is a ``view``",|Complete|,14.0
-`P2432 <https://wg21.link/P2432>`__,"Fix ``istream_view``",,
+"Number","Name","Status"
+"`3173 <https://wg21.link/LWG3173>`__","Enable CTAD for ``ref-view``\ ",✅
----------------
Mordante wrote:
> ldionne wrote:
> > Do we need that separate page? Can't we track those using the normal C++20/C++23 issues page?
> We indeed removed issues from the status pages in the past. I don't mind to keep them. Looking at the huge list of issues I can imagine tracking them on one page is easier; even when it duplicates entries. (Something tells me C++26 will add new LWG issues for ranges.)
Honestly, I'm torn about this. Neither keeping two large lists in sync (when they are almost guaranteed to diverge) nor having to scoop around a huge list of papers searching for a certain tag seems great. I wish it were possible to import only a subset of a CSV table, filtered by a tag, but I'd be surprised if it were a supported option.

After discussing this with @ldionne, I decided to drop the duplication. IIUC, we will switch to using GitHub issues to track these at some point, so ultimately it's not super important how we approach this.


================
Comment at: libcxx/docs/Status/RangesPapers.csv:1
+"Number","Name","Status"
+"`P0896R4 <https://wg21.link/P0896R4>`__","The One Ranges Proposal",✅
----------------
ldionne wrote:
> Same here -- why don't we track that from the C++20/C++23 papers page instead?
Removed now.


================
Comment at: libcxx/docs/Status/RangesPapers.csv:51
+"`P2278R4 <https://wg21.link/P2278R4>`__","``cbegin`` should always return a constant iterator","Not started"
+"`P2286R8 <https://wg21.link/P2286R8>`__","Formatting Ranges","Not started"
+"`P2302R4 <https://wg21.link/P2302R4>`__","``std::ranges::contains``","Not started"
----------------
Mordante wrote:
> This is not true; parts have already landed ;-) I already track this on the format status page. (https://libcxx.llvm.org/Status/Format.html)
This is great! And thank you for the heads-up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136657/new/

https://reviews.llvm.org/D136657



More information about the libcxx-commits mailing list