[PATCH] D134772: [Clang] Make constraints of auto part of NTTP instead of AutoType

Tue Sep 27 17:41:16 PDT 2022

ychen added a comment.

@rsmith, thanks for chiming in.

In D134772#3819502 <https://reviews.llvm.org/D134772#3819502>, @rsmith wrote:

> I'm somewhat skeptical of this approach, because constrained `auto` can appear in places within the type of an NTTP other than the top level -- for example, in `template<C auto*>`. (Clang is non-conforming and doesn't support this yet, but it will need to do so eventually.)

Yep, I'm aware of the cases like `template<C auto*>`/`template<C auto&>`/`template<C decltype(auto)>`. It would need to retrieve the deduced type explicitly and the difference this patch brings is to look for the constraints from NTTP instead. It is not geat but doable.

> In principle, there could even be multiple different constrained `auto` types within the type of the same NTTP in the future -- I don't think that can happen with the current language rules, but it could happen in the Concepts TS, and it only seems to be happenstance that prevents it in C++20 rather than design intent. Fundamentally, the constraint is not associated with the NTTP and is instead associated with the relevant portion of the NTTP's type.

I fully agree that fundamentally the constraint is associated with auto (the syntax rule suggests that too). I didn't think of the possibility that `multiple different constrained auto types within the type of the same NTTP`. It is very interesting. Any chance this approach could be tuned for that future use case? Like maintaining an array of constrains for the NTTP?

> If something in the design of constrained `auto` is meaning that uniquing isn't working properly, maybe there's some way we can address that directly?

I gave a lot of thought to it but couldn't find a satisfactory approach. One way is to recreate injected template argument for constrained `auto` NTTP, but without the constraint, then use that the instantiate all the types I need for the partial ordering. It is definitely doable but pretty expensive. Any suggestions are greatly appreciated. :-)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134772