https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100594
Bug ID: 100594
Summary: Lambdas in unevaluated contexts interact oddly with
alias templates
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: brycelelbach at gmail dot com
Target Milestone: ---
This code:
```
template <typename T> struct identity {};
template <int N>
using A = decltype([] () constexpr { return int{}; }());
template <int N>
using B = identity<A<N>>;
```
Is incorrectly rejected by GCC in C++20 mode:
```
<source>:7:23: error: template argument 1 is invalid
7 | using B = identity<A<N>>;
| ^~
ASM generation compiler returned: 1
<source>:7:23: error: template argument 1 is invalid
7 | using B = identity<A<N>>;
| ^~
Execution build compiler returned: 1
```
https://godbolt.org/z/hGjfvjGzc
For context, I ran into this while writing this code:
https://godbolt.org/z/36xz8zGMd
I discussed this with Ville and Jason via email:
Ville wrote:
> Specifically looks like there's an interaction with an alias template
> here, because
>
> decltype([] () constexpr { return int{}; }())* oink;
> static_assert(std::is_same_v<decltype(oink), int*>);
>
> is just fine according to GCC.
Jason wrote:
> Yeah, how (unevaluated) lambdas should interact with alias templates is
> unclear, connected to various existing alias template issues around exactly
> how transparent (or not) they are.
>
> You could work around this with a class template or variable template
> that forces the lambda instantiation to be delayed until we have a full
> set of template arguments.
