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

[Vadim Zeitlin]

On Tue, 27 Apr 2021 21:26:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> > GC>     Unfortunately the shorthand
GC> > GC>       default: ==, !=, <, >, <=, >=;
GC> > GC>     proposed in
GC> > GC>       
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2014/n4126.htm
GC> > GC>     has not been embraced by C++20.
GC> 
GC> That's the part that I really wish you had found reason to correct,
GC> as the idea of overloading "default:" tickled me.

 I must admit I don't see anything wrong with this, but it may well be a
professional deformation of a long-term C++ programmer. I.e. it seems
pretty C++-ish to me to reuse the existing keyword and it seems to play a
very logical role here. And, to just think how much worse it could have
been, at least they didn't overload "static" for this!

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

 To be honest, I'm not sure if this is the correct reading, but my main
point is that in practice the only 3 existing C++20 implementations don't
do this and I consider it extremely unlikely that any implementation
appearing in the future would make a choice to be intentionally
incompatible with the existing ones in such a basic way.

 So the question is whether the extra verbosity is worth the potential
gain in correctness that will almost surely be exactly 0 in practice. IMO
it isn't, but I won't argue any more if you disagree.

GC> The gcc documentation here:
GC>   https://www.gnu.org/software/gcc/projects/cxx-status.html
GC> tells us to test for
GC> |   __cpp_impl_three_way_comparison >= 201711
GC> (with no "L" suffix) although C++20 (N4861) specifies "201907L".
GC> 
GC> AIUI, testing for the earlier "201711L" would indicate that
GC> we had an earlier version of the feature, which would have
GC> been okay in this instance. The date-value was proposed to
GC> be bumped here:
GC>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1186r3.html
GC> but then it was proposed to be bumped not there, but here:
GC>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1630r1.html
GC> and the situation seemed so confusing that it seemed best
GC> to follow SD-6 despite its ""in most cases" weasel words.

 This is a good argument for not testing for any fixed value, as we know
that our code works with any implementation of this feature (as long as it
remains backwards-compatible, but I hope we can still at least make this
assumption). I don't think it's a good argument for testing for 0.

 Regards,
VZ

pgpsYFCpyCD0A.pgp
Description: PGP signature