[PATCH] D128750: [c++20] Implement P2113R0: Changes to the Partial Ordering of Constrained Functions

[Yuanfang Chen via Phabricator via cfe-commits]

ychen marked an inline comment as done.
ychen added a comment.

In D128750#3627085 <https://reviews.llvm.org/D128750#3627085>, @royjacobson wrote:

> I'm also a bit concerned that we're deviating from the standard here w.r.t. to the 'reordering' checks for reversed candidates. I support this - I think your version makes more sense than what the standard says to do here - but if someone could check with the committee (I don't have reflector access myself) that we're not breaking some important use case by doing it this way, I think it's a good idea.

I gave this more thought and think the current approach of using deduce order does not contradict the standardese.

The reason is that there is only one way to reorder the function parameter lists of rewritten candidates because they are all binary operators. Hence "reorder" simply means "reverse". Also, https://eel.is/c++draft/temp.func.order#6.2.1.2.2 says "the function parameters that *positionally correspond* between the two templates are of the same type,". My understanding is that *positionally correspond* and *reverse* dictates that either zero or one reordering works, but not two or more. This is also based on the assumption that rewritten candidates can only have two operands, which I believe is true as of C++20, not sure about it in the future.

For example, in

  template <typename> constexpr bool True = true;
  template <typename T> concept C = True<T>;
  template <typename T, typename U> struct X { };
  
  template <C T, typename U, typename V> bool operator==(X<T, U>, V);
  template <C V, C U, typename T>        bool operator==(T, X<U, V>); // rewritten candidate

suppose reordering the rewritten candidate's template parameters list as the below works:

  template <C U, C V, typename T>        bool operator==(X<U, V>, T); // rewritten candidate

There is *no* way to reorder the template parameters list again (to get two or more reordering) and the resulted template still works, because of the *positionally correspond* requirement. If this reasoning is sound, I think the current approach of deducing order to compare constraints for rewritten candidates is correct. I wouldn't say I'm 100% confident. But it still makes sense to me at this moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128750