https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
waffl3x <waffl3x at protonmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |waffl3x at protonmail dot com
--- Comment #2 from waffl3x <waffl3x at protonmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I suspect PR 109181 is the same (or rather reduced example).
Yes, I believe the case danakj wrote here is very close to my original use case
when I first submitted the bug. Since I never got around to recreating it and
posting it I'm thankful this report was made, I had mostly forgotten about it.
I found 2 workarounds so I ended up moving on.
I suspect that the bug isn't related to partial specializations given the
reduced case in PR 109181 doesn't have one, however, my original case also
involved partial specializations so perhaps I am wrong.
Here are the workarounds I mentioned just in case they are useful to danakj.
The first workaround is more modern, not resorting to older techniques.
```
template<typename T>
concept HasTypeMemberTemplate1 = requires{
typename std::type_identity<decltype(std::declval<typename
my_template<T>::template type<>>())>;
};
```
The second workaround uses older techniques.
```
template<typename T, typename = void>
struct specialization_has_type_member_template
: std::false_type {};
template<typename T>
struct specialization_has_type_member_template<T, std::void_t<typename
my_template<T>::template type<>>>
: std::true_type {};
template<typename T>
concept HasTypeMemberTemplate2 = has_valid_adapter_specialization<T>::value;
```
You can see both workarounds in action here, hopefully you can get some use out
of them.
https://godbolt.org/z/Po1M4qc5P
I can't take credit for the modern workaround, someone named Raldryniorth in a
small community came up with it when I had the problem months back, so thanks
to him for that.
