__cpp_lib_three_way_comparison not defined when it should be

[QrczakMK]

https://godbolt.org/z/z67c5EErb

The following code fails the #error with -std=c++20 -stdlib=libc++:

#include <compare>
#include <version>

std::strong_ordering Test(int a, int b) {
  return a <=> b;
}

#if defined(__cpp_impl_three_way_comparison) && \
    !defined(__cpp_lib_three_way_comparison)
#error The library supports three-way comparison but claims it does not
#endif

[llvmbot]

@llvm/issue-subscribers-c-20

Author: Marcin Kowalczyk (QrczakMK)

https://godbolt.org/z/z67c5EErb

The following code fails the #error with -std=c++20 -stdlib=libc++:

#include <compare>
#include <version>

std::strong_ordering Test(int a, int b) {
  return a <=> b;
}

#if defined(__cpp_impl_three_way_comparison) && \
    !defined(__cpp_lib_three_way_comparison)
#error The library supports three-way comparison but claims it does not
#endif

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Marcin Kowalczyk (QrczakMK)

https://godbolt.org/z/z67c5EErb

The following code fails the #error with -std=c++20 -stdlib=libc++:

#include <compare>
#include <version>

std::strong_ordering Test(int a, int b) {
  return a <=> b;
}

#if defined(__cpp_impl_three_way_comparison) && \
    !defined(__cpp_lib_three_way_comparison)
#error The library supports three-way comparison but claims it does not
#endif

[shafik]

Is this a libc++ issue? https://godbolt.org/z/cP17dKohM

CC @ldionne @AaronBallman

[h-vetinari]

These are two different macros, one for language support, one for libcxx support. There's a status page for the implementation of the latter. It's essentially complete, though blocked on full chrono and stacktrace support, which is why the macro isn't set yet.

Arguably, one could set __cpp_lib_three_way_comparison and just include the spaceship¹ bits for chrono/stacktrace in the respective feature macros, but that's up to the libcxx maintainers.

Footnotes

1. the situation is very similar for (C++20) _cpp_lib_format, which is also complete except chrono/stacktrace. ↩

[philnik777]

The stacktrace parts aren't actually part of P1614. I think it would be reasonable to enable the FTM, since we'll implement the spaceship operator for the chrono parts and never provide all the overloads anyways. You'd want to check __cpp_lib_chrono if you want to use chrono. @mordante any thoughts on this, since you're working on the chrono parts?

[mordante]

I don't think we should enable the FTM; our implementation is not complete. The incomplete state of chrono also prevents setting the format FTM. For spaceship we also lack the implementation of std::strong_order(long double, long double).

(It would have been great if larger features would have more fine-grained FTM like the latest freestanding papers did.)

As for the chrono parts I have some local patches which I still need to cleanup and publish. It's mainly a lack of time to get them out.

[h-vetinari]

The incomplete state of chrono also prevents setting the format FTM

This part I don't fully understand TBH. It's obvious that there cannot be formatters for something not implemented yet, so expecting chrono formatters if __cpp_lib_chrono is not set, just because the format FTM is set, seems backwards to me.

From the POV, I'd argue that _cpp_lib_format could be set already, with the only caveat that setting __cpp_lib_chrono then needs to wait for both the chrono implementation and the formatters.

Aside from the missing strong_order, I think the same logic would also apply to spaceship...

[mordante]

The incomplete state of chrono also prevents setting the format FTM

This part I don't fully understand TBH. It's obvious that there cannot be formatters for something not implemented yet, so expecting chrono formatters if __cpp_lib_chrono is not set, just because the format FTM is set, seems backwards to me.

From the POV, I'd argue that _cpp_lib_format could be set already, with the only caveat that setting __cpp_lib_chrono then needs to wait for both the chrono implementation and the formatters.

It does not matter whether you or I think this is a good design. It only matters what the Standard says. Per
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_lib_format setting __cpp_lib_format requires the chrono formatters. (This matches the wording of the individual plenary approved papers.)

Setting the FTM to that value tells users the paper has been fully implemented in libc++. Also I expect to set the format FTM before the chrono library is complete. For formatting I don't need to implement the parsing part of chrono.

[jyknight]

The Standard does not have such a requirement -- it simply requires that all of the FTMs are defined. The doc you link is a recommendation for what a non-standards-compliant implementation (such as ours) might wish to do.

It is clear that in fact, formatting of chrono types requires both chrono and formatting to be implemented, and I would argue that it's entirely within our power to make a reasonable choice of which macros to define based on which functionality is available. (As long as ultimately, when both are supported, all the expected functionality is there.) It's just a question of what serves users best, not of standards-conformance.

I do not believe the intent of the recommendations doc was to completely explore and specify the entire cross-product of potential missing features. Rather, it's just listed in that way only because chrono landed in the spec before format. If chrono had landed after format, then the formatting parts of chrono would've been in the original chrono proposal, and thus part of the chrono feature. In that alternative world, I'd argue that it would be entirely correct to claim full support for the chrono feature, even if we had not implemented the formatting library at all (and thus, couldn't provide chrono formatters).