Re: [lmi] [lmi-commits] odd/gpt e293170 1/5: Add an equality operator

[Greg Chicares]

On 4/27/21 6:19 PM, Vadim Zeitlin wrote:
> On Tue, 27 Apr 2021 12:13:45 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: odd/gpt
> GC> commit e2931707d25f64eba0db41696c78a60c19cf8d10
> GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> 
> GC>     Add an equality operator
> GC>     
> GC>     It is anticipated that all but one line of this change will be 
> expunged
> GC>     soon enough.

When I wrote that, I didn't realize how very soon that would be.

> GC>     Unfortunately the shorthand
> GC>       default: ==, !=, <, >, <=, >=;
> GC>     proposed in
> GC>       http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4126.htm
> GC>     has not been embraced by C++20.

That's the part that I really wish you had found reason to correct,
as the idea of overloading "default:" tickled me.

> GC>     SD-6 says: "in most cases it is expected that the presence of a 
> feature
> GC>     can be determined by the presence of any non-zero macro value".
> 
>  Interesting, I was sure that just being defined was enough. And
> https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros seems
> to confirm it, even though it's non-normative.
[...]
> GC> +#if defined __cpp_impl_three_way_comparison && 
> __cpp_impl_three_way_comparison
> 
>  I.e. I believe that the part after "&&" is not really necessary here and
> if we did want to be pedantic, I'd check for
> 
>       #if defined __cpp_impl_three_way_comparison && 
> __cpp_impl_three_way_comparison >= 201907
> 
> But, again, IMO a simple check for defined-ness should really be enough
> (and this is what I used for checking for "__cpp_char8_t").

As I read SD-6, an implementation is free to define any of these
macros to be zero, even if it doesn't support the corresponding
feature.

The gcc documentation here:
  https://www.gnu.org/software/gcc/projects/cxx-status.html
tells us to test for
|   __cpp_impl_three_way_comparison >= 201711
(with no "L" suffix) although C++20 (N4861) specifies "201907L".

AIUI, testing for the earlier "201711L" would indicate that
we had an earlier version of the feature, which would have
been okay in this instance. The date-value was proposed to
be bumped here:
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1186r3.html
but then it was proposed to be bumped not there, but here:
  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1630r1.html
and the situation seemed so confusing that it seemed best
to follow SD-6 despite its ""in most cases" weasel words.