First of all, I am sorry for my late response as I missed your email.
I need to update my filter setup of gmail after switching from hotmail.
>I think WILDCARD_TYPE_P is what you want, except...
I will try this one.
>Your patch rejects that testcase even without the specialization on
>int[], which no other compiler I'm aware of does;
Honestly I now realize this is a wakeup call for me as I have been
trying to revert PR92010 approach for months as I at that time favor
the early syntax-checking approach which is considered efficient. Now
your testcase reveals me a realist practice that almost all compilers
tolerate this seemingly user's definition error because:
a) It actually follows the principle that template without instantiation
might not give error.
b) "const T" and "T" maybe turn out to be the same after instantiation
as function parameter.
So, I guess this is the real practical approach for most compilers to
rebuild function signature from declaration only when instantiation.
My approach stucks when GCC search declaration for definition because
"T" and "const T" are two different CANONICAL types. So, I now guess
that is why declarator deliberately drops cv-qualifers to tolerate your
testcase.
>You seem to have missed my September 28 mail that argued for fixing the
>bug in determine_specialization that was preventing the 92010 fix from
>handling these cases.
I did try to see this approach, but I was stuck in a sidelined issue of
PR102624 which relates to lambda-in-unevaluated-context. The point is
that I thought PR92010 starts to satisfy this pt.c:tsubst_default_argument:
gcc_assert (same_type_ignoring_top_level_qualifiers_p (type, parmtype));
But I think after introduction of lambda in unevaluated context, this may
not be correct assertion. I could be wrong on this. However, i.e.
template <class T>
void spam(decltype([]{})* ptr=nullptr)
{ }
void foo(){
spam<int>();
}
When rebuilding lambda type from declaration, it is always a unique
different type. So, that is the reason I thought this rebuild function
type approach is imperfect. In other words, it is no good to rebuild
function type to satisfy this may-not-be-correct-assertion,
Anyway, I now think PR92010 is practically a good approach and I will
start testing your patch.
Best regards,
