<div dir="ltr"><div dir="ltr">On Thu, 12 Mar 2020 at 15:14, Romain GEISSLER via cfe-users <<a href="mailto:cfe-users@lists.llvm.org">cfe-users@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
It looks like the working of C++20 introduced some breaking compatibilities with some C++17 accepted patterns. From what I read in <a href="https://reviews.llvm.org/rL375306" rel="noreferrer" target="_blank">https://reviews.llvm.org/rL375306</a> these incompatibilities weren’t really intented by the initial C++20 proposal, and thus broken patterns were still allowed as an extension, but would warn with -Wambiguous-reversed-operator enabled by default. Richard Smith had some hope that the C++20 standard would be fixed before being final.<br>
<br>
C++20 is not fully finalized yet, but this date is approaching. What’s the state of the standard now ? Have the comparison issues been fixed ?</blockquote><div><br></div><div>No, we still don't have a resolution from the C++ committee, but it's being discussed by various implementers, and we hope to present to the committee a suggested set of changes to minimize the pain to users as soon as we can. I expect we will change /something/ as a DR fix against C++20, but the exact details are unclear.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If not, what do you suggest to users ? Fix the code (when it’s actually possible and make sense), or compile with -Wno-ambiguous-reversed-operator ? I am asking this question in the particular case of boost date_time: <a href="https://github.com/boostorg/date_time/issues/132" rel="noreferrer" target="_blank">https://github.com/boostorg/date_time/issues/132</a> where I am actually unsure this is a good idea to change the existing code.<br></blockquote><div><br></div><div>If you can change the code in a way that's compatible with the C++20 rules, that will give you the best portability across compilers in the short term. If Boost is prepared to wait until this is fixed before supporting -std=c++20, then that would seem reasonable too. </div></div></div>