[libc++] Document that libc++ does not and will never implement the Networking TS #127508
Conversation
…etworking TS There has been discussion around this a few times already, and there seemed to be consensus that we would never pursue an implementation of the Networking TS. This patch solidifies that discussion by documenting it and closing issues related to the Networking TS. Closes llvm#103799, llvm#100223, llvm#100228, llvm#100231, llvm#100232
llvmbot
added
the
libc++
|
@llvm/pr-subscribers-libcxx Author: Louis Dionne (ldionne) ChangesThere has been discussion around this a few times already, and there seemed to be consensus that we would never pursue an implementation of the Networking TS. This patch solidifies that discussion by documenting it and closing issues related to the Networking TS. Closes #103799, #100223, #100228, #100231, #100232 Full diff: https://github.com/llvm/llvm-project/pull/127508.diff 2 Files Affected:
diff --git a/libcxx/docs/DesignDocs/ExperimentalFeatures.rst b/libcxx/docs/DesignDocs/ExperimentalFeatures.rst
index dc2ae6a25aa5d..0dbbd5f869e36 100644
--- a/libcxx/docs/DesignDocs/ExperimentalFeatures.rst
+++ b/libcxx/docs/DesignDocs/ExperimentalFeatures.rst
@@ -160,8 +160,8 @@ has been removed in LLVM 17.0.
`Networking TS <https://wg21.link/N4656>`__
-------------------------------------------
-The Networking TS is not yet part of a shipping standard.
-We have not yet shipped an implementation of the Networking TS.
+The Networking TS is not yet part of a shipping standard, and there is discussion around removing it.
+Libc++ never shipped an implementation of the Networking TS and does not plan to do so in the future.
`Ranges TS <https://wg21.link/N4685>`__
---------------------------------------
diff --git a/libcxx/docs/Status/Cxx20Issues.csv b/libcxx/docs/Status/Cxx20Issues.csv
index 3462557e8d668..1b8e76d90d9ef 100644
--- a/libcxx/docs/Status/Cxx20Issues.csv
+++ b/libcxx/docs/Status/Cxx20Issues.csv
@@ -13,7 +13,7 @@
"`LWG2966 <https://wg21.link/LWG2966>`__","Incomplete resolution of US 74","2017-07 (Toronto)","|Nothing To Do|","",""
"`LWG2974 <https://wg21.link/LWG2974>`__","Diagnose out of bounds ``tuple_element/variant_alternative``\ ","2017-07 (Toronto)","|Complete|","",""
"","","","","",""
-"`LWG2779 <https://wg21.link/LWG2779>`__","[networking.ts] Relax requirements on buffer sequence iterators","2017-11 (Albuquerque)","","",""
+"`LWG2779 <https://wg21.link/LWG2779>`__","[networking.ts] Relax requirements on buffer sequence iterators","2017-11 (Albuquerque)","|Nothing To Do|","",""
"`LWG2870 <https://wg21.link/LWG2870>`__","Default value of parameter theta of polar should be dependent","2017-11 (Albuquerque)","|Complete|","",""
"`LWG2935 <https://wg21.link/LWG2935>`__","What should create_directories do when p already exists but is not a directory?","2017-11 (Albuquerque)","|Nothing To Do|","",""
"`LWG2941 <https://wg21.link/LWG2941>`__","[thread.req.timing] wording should apply to both member and namespace-level functions","2017-11 (Albuquerque)","|Nothing To Do|","",""
@@ -51,17 +51,17 @@
"`LWG2975 <https://wg21.link/LWG2975>`__","Missing case for ``pair``\ construction in scoped and polymorphic allocators","2018-03 (Jacksonville)","","",""
"`LWG2989 <https://wg21.link/LWG2989>`__","``path``\ 's stream insertion operator lets you insert everything under the sun","2018-03 (Jacksonville)","|Complete|","",""
"`LWG3000 <https://wg21.link/LWG3000>`__","``monotonic_memory_resource::do_is_equal``\ uses ``dynamic_cast``\ unnecessarily","2018-03 (Jacksonville)","|Complete|","16",""
-"`LWG3002 <https://wg21.link/LWG3002>`__","[networking.ts] ``basic_socket_acceptor::is_open()``\ isn't ``noexcept``\ ","2018-03 (Jacksonville)","","",""
+"`LWG3002 <https://wg21.link/LWG3002>`__","[networking.ts] ``basic_socket_acceptor::is_open()``\ isn't ``noexcept``\ ","2018-03 (Jacksonville)","|Nothing To Do|","",""
"`LWG3004 <https://wg21.link/LWG3004>`__","|sect|\ [string.capacity] and |sect|\ [vector.capacity] should specify time complexity for ``capacity()``\ ","2018-03 (Jacksonville)","|Nothing To Do|","",""
"`LWG3005 <https://wg21.link/LWG3005>`__","Destruction order of arrays by ``make_shared/allocate_shared``\ only recommended?","2018-03 (Jacksonville)","","",""
"`LWG3007 <https://wg21.link/LWG3007>`__","``allocate_shared``\ should rebind allocator to *cv*-unqualified ``value_type``\ for construction","2018-03 (Jacksonville)","","",""
"`LWG3009 <https://wg21.link/LWG3009>`__","Including ``<string_view>``\ doesn't provide ``std::size/empty/data``\ ","2018-03 (Jacksonville)","|Complete|","",""
-"`LWG3010 <https://wg21.link/LWG3010>`__","[networking.ts] ``uses_executor``\ says ""if a type ``T::executor_type``\ exists""","2018-03 (Jacksonville)","","",""
+"`LWG3010 <https://wg21.link/LWG3010>`__","[networking.ts] ``uses_executor``\ says ""if a type ``T::executor_type``\ exists""","2018-03 (Jacksonville)","|Nothing To Do|","",""
"`LWG3013 <https://wg21.link/LWG3013>`__","``(recursive_)directory_iterator``\ construction and traversal should not be ``noexcept``\ ","2018-03 (Jacksonville)","|Complete|","",""
"`LWG3014 <https://wg21.link/LWG3014>`__","More ``noexcept``\ issues with filesystem operations","2018-03 (Jacksonville)","|Complete|","",""
"`LWG3015 <https://wg21.link/LWG3015>`__","``copy_options::*unspecified*``\ underspecified","2018-03 (Jacksonville)","|Nothing To Do|","",""
"`LWG3017 <https://wg21.link/LWG3017>`__","``list splice``\ functions should use ``addressof``\ ","2018-03 (Jacksonville)","|Complete|","",""
-"`LWG3020 <https://wg21.link/LWG3020>`__","[networking.ts] Remove spurious nested ``value_type``\ buffer sequence requirement","2018-03 (Jacksonville)","","",""
+"`LWG3020 <https://wg21.link/LWG3020>`__","[networking.ts] Remove spurious nested ``value_type``\ buffer sequence requirement","2018-03 (Jacksonville)","|Nothing To Do|","",""
"`LWG3026 <https://wg21.link/LWG3026>`__","``filesystem::weakly_canonical``\ still defined in terms of ``canonical(p, base)``\ ","2018-03 (Jacksonville)","|Complete|","",""
"`LWG3030 <https://wg21.link/LWG3030>`__","Who shall meet the requirements of ``try_lock``\ ?","2018-03 (Jacksonville)","|Nothing To Do|","",""
"`LWG3034 <https://wg21.link/LWG3034>`__","P0767R1 breaks previously-standard-layout types","2018-03 (Jacksonville)","|Complete|","",""
|
| The Networking TS is not yet part of a shipping standard, and there is discussion around removing it. | ||
| Libc++ never shipped an implementation of the Networking TS and does not plan to do so in the future. |
There was a problem hiding this comment.
I think I'd like to keep the wording open to accepting an implementation if there is any new momentum on merging it into the standard and there is someone stepping up to implement it.
There was a problem hiding this comment.
If there is any momentum to merge the TS in the Standard we can revise this position. With the work on senders and receivers I don't expect there be to any desire in the Committee to move the TS in its current shape in the Standard.
There was a problem hiding this comment.
There is actually discussion in WG21 about removing the TS entirely. I think it's widely understood that the Networking TS will never be merged into the IS. Given that, I'd be reluctant to accept an implementation of the TS since that would increase our surface area, maintenance burden, etc for something that will never land in the IS, which is not worth it. WDYT?
There was a problem hiding this comment.
I don't expect that we will ever implement it, but I also don't want to close the door entirely until the committee does so too. Note that I would still predicate adopting an implementation on there being effort to merge it into the IS, which I also don't expect will ever happen. It's more about how we deal with stale TSes than anything else.
There was a problem hiding this comment.
Libc++ never shipped an implementation of the Networking TS and does not plan to do so in the future, unless the C++ Standards Committee expresses a desire to merge the Networking TS into the IS (which is unlikely at this point).
Would that capture what you want?
There was a problem hiding this comment.
My main concern for accepting such a hypothetical patch is, that it will take a lot of review time and not give any more implementation experience of the TS in question. Since we're not really able to keep up with patches I feel we should reject such patches.
If somebody would have done the effort say 4 years ago I would have a different opinion.
Should we add this to the agenda for the next monthly?
There was a problem hiding this comment.
Yes, sounds good to me.
There was a problem hiding this comment.
My main concern for accepting such a hypothetical patch is, that it will take a lot of review time and not give any more implementation experience of the TS in question. Since we're not really able to keep up with patches I feel we should reject such patches.
I think we are all in agreement about this. I think @philnik777 's request is to acknowledge that IF WG21 decided tomorrow that we're going to merge Networking TS into the IS, and IF someone came and contributed a full implementation, then we would accept it. And I think we all agree that we would.
But that's almost certainly not going to happen, because WG21 will not pursue merging the TS, and consequently if someone came with a full patch, we'd likely say "sorry but we're not going to add something that we know is never going to be merged into the IS and is super complicated to review and maintain".
There was a problem hiding this comment.
My main concern for accepting such a hypothetical patch is, that it will take a lot of review time and not give any more implementation experience of the TS in question. Since we're not really able to keep up with patches I feel we should reject such patches.
I think we are all in agreement about this. I think @philnik777 's request is to acknowledge that IF WG21 decided tomorrow that we're going to merge Networking TS into the IS, and IF someone came and contributed a full implementation, then we would accept it. And I think we all agree that we would.
But that's almost certainly not going to happen, because WG21 will not pursue merging the TS, and consequently if someone came with a full patch, we'd likely say "sorry but we're not going to add something that we know is never going to be merged into the IS and is super complicated to review and maintain".
Yes, that's my position.
| @@ -13,7 +13,7 @@ | |||
| "`LWG2966 <https://wg21.link/LWG2966>`__","Incomplete resolution of US 74","2017-07 (Toronto)","|Nothing To Do|","","" | |||
| "`LWG2974 <https://wg21.link/LWG2974>`__","Diagnose out of bounds ``tuple_element/variant_alternative``\ ","2017-07 (Toronto)","|Complete|","","" | |||
| "","","","","","" | |||
| "`LWG2779 <https://wg21.link/LWG2779>`__","[networking.ts] Relax requirements on buffer sequence iterators","2017-11 (Albuquerque)","","","" | |||
| "`LWG2779 <https://wg21.link/LWG2779>`__","[networking.ts] Relax requirements on buffer sequence iterators","2017-11 (Albuquerque)","|Nothing To Do|","","" | |||
There was a problem hiding this comment.
I'm not sure "Nothing to do" is the right thing here. Maybe "Not applicable"?
There was a problem hiding this comment.
I agree, I thought of this too. My only concern is that it would add complexity to the Github issues synchronization stuff for a "status" we will basically never be using except for the Networking TS. Another option would be to rename "Nothing To Do" to "Not Applicable", or to leave it be "Nothing To Do" but to widen its description. WDYT?
There has been discussion around this a few times already, and there seemed to be consensus that we would never pursue an implementation of the Networking TS. This patch solidifies that discussion by documenting it and closing issues related to the Networking TS.
Closes #103799
Closes #100223
Closes #100228
Closes #100231
Closes #100232