[libcxx-commits] [PATCH] D111773: [libcxx] __cpp_lib_ranges value should be 201911L under C++20, not 201811L

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added inline comments.


================
Comment at: libcxx/utils/generate_feature_test_macro_components.py:491-494
     "name": "__cpp_lib_ranges",
-    "values": { "c++20": 201811 },
+    "values": { "c++20": 201911 },
     "headers": ["algorithm", "functional", "iterator", "memory", "ranges"],
     "unimplemented": True,
----------------
Quuxplusone wrote:
> Mordante wrote:
> > Quuxplusone wrote:
> > > I think this change from 201811 to 201911 is correct. I'm willing to commandeer and land this 1-character-plus-autogenerated-files change. @ldionne, thoughts?
> > > https://timsong-cpp.github.io/cppwp/n4861/version.syn#lib:__cpp_lib_ranges
> > > 
> > > However, notice the `"unimplemented": True`. That's correct as-is, because libc++ does //not// yet fully implement C++20 Ranges. We'll define the feature-test macro only once we have implemented the feature; that's what it's for!
> > IMO we should only bump it when we start/have started to work on the papers that increment this value. It might be we finish the part that requires 201811 before we finish the papers that required 201911.
> Oh, [p0896] actually did set it to `201811` (and confirmed by [p1458r1](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1458r1.pdf))! Okay then.
> I wish there were an authoritative list of all possible feature-test macro values and what they mean. The closest I know of is https://en.cppreference.com/w/cpp/feature_test but it doesn't list things at paper granularity, like, [p0896]; it lists only what the value is for each released standard (like, C++20 as a whole). For example, that page doesn't list `201811` as a possible value for `__cpp_lib_ranges` (presumably because no International Standard was ever released with that specific value).
> 
> That said, given that there's no authoritative source for what `201811` is supposed to mean, I'm also not sure how we'd ever figure out that it's okay to bump libc++'s macro value from `unimplemented` to `implemented`, let alone from `201811` to `201911`. The only 100% safe thing I can see is that once we've implemented 100% of the C++20 IS, then we can definitely bump it to `201911` because that's what the C++20 IS says it should be.
There's an authoritative source. That's the paper that changed the version number. I'm not aware of a location where that information can easily be found. So I hope the people working on implementing the papers keep track of it. For `<format>` I know which 3 papers give a version bump. (Fun fact C++20 format will get a feature-test macro with the value of `202110` due to a paper being retroactively applied to C++20 at the last plenary.)


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

https://reviews.llvm.org/D111773