https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #8 from Steven Sun ---
under c++17
Step 4 needs `types_match == 1` [at 1] but, its value is zero, which is caused
by `function_requirements_equivalent_p` [at 3] returns 0 [at 2] .
[1]
https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #7 from Steven Sun ---
After digging for two days, I think I may know what's happening inside.
Under std=c++20 and my code in comment 1, the flow when parsing a full function
specialization would be
1. Found a full specialization o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #6 from Steven Sun ---
While in C++20, the complier thinks it's unnecessary to instatiate a new
template. Just use the full specialization! Thus, this bug wouldn't exist at
first place.
Intuitively, I am in favor of the compiler's C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #5 from Steven Sun ---
I learn a little about gcc recently. I think I got a vague idea of what's going
on inside.
In c++17 mode with concepts, and with my code in comment 1.
The compiler decides to instantiate from the concept const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #4 from W E Brown ---
(In reply to Steven Sun from comment #3)
> I would expect the complete specialization is full
> specialization for both primary templates.
No, any given explicit or partial specialization can be a specializ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
--- Comment #3 from Steven Sun ---
@W E Brown: I got your idea. So are all uses like this ill-formed? This seems
unexpected for me. I would expect the complete specialization is full
specialization for both primary templates.
I also find facts t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment #2
