https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107875

            Bug ID: 107875
           Summary: Deduction for class template specialization types
                    seems to be broken with init-declarator-list
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: 8ygd87qg at gmail dot com
  Target Milestone: ---

Consider the following program (compiled with -std=c++20):

#include <type_traits>
template <auto f = []{}>
struct X {};
X x1, x2;
static_assert(!std::is_same_v<decltype(x1), decltype(x2)>);
int main() {}

Relevant godbolt link: https://godbolt.org/z/h9Wd4K7sn

According to https://eel.is/c++draft/dcl.type.class.deduct#1, it seems that
type deduction should be done for x1 and x2 separately, and they should have
the same type (and if they don't, then the compilation should at least give a
diagnostic, perhaps an error). I am not well-versed with standardese, so please
bear with me if something is wrong (and please point out if the standard seems
to be ambiguous in this case).

When x1 and x2 are declared in separate statements (like X x1; X x2;), they
should have different types since the lambda in the template parameter
specialization always has a distinct type whenever it is called. So if type
deduction is carried out for x1 and x2 separately in the first example, they
should have different types (even if somehow they're assigned the same types,
the static_assert should fail).

In any case, the above program should not compile. However, GCC trunk and
12.2.1 both seem to allow this program to compile. Clang however seems to have
an expected behavior and gives the following error:

<source>:4:1: error: template arguments deduced as 'X<(lambda at
<source>:2:20){}>' in declaration of 'x1' and deduced as 'X<(lambda at
<source>:2:20){}>' in declaration of 'x2'
X x1, x2;
^ ~~  ~~
1 error generated.
Compiler returned: 1

It'd be great if this is fixed in case it turns out to be a bug. Thanks!

Reply via email to