Christopher Hallock <christopherhallock_at_[hidden]> 于2020年8月21日周五 下午5:21写道：
>
>
>
> On Thu, Aug 20, 2020 at 11:36 PM jim x via Std-Discussion <std-discussion_at_[hidden]> wrote:
>>
>> Hi, everyone. please consider the below code:
>>
>> ````
>> template<typename T>
>> void func(){
>> struct Test{};
>> show(Test{});
>> }
>> void show(...){
>> }
>> int main(){
>> func<int>();
>> }
>> ````
>> There is no any rule in [temp.dep.type] to specify the local class
>> declared within function template may be considered as dependent type.
>> So, I think the name lookup for `show` should be bound at the point it
>> is used. The second phase name lookup shouldn't occur due to `show` is
>> not a dependent-name, at least according to the definition of
>> dependent-name in section [temp.dep]. However, current implementations
>> all consider `show` as a dependent-name which will be found by ADL in
>> the context of instantiation, that is, The local class `Test` is
>> viewed as dependent-type. If I don't misunderstand the section
>> [temp.dep.type], how would `Test` be a dependent-type? For such a
>> local class, Is it a case missed in the section [temp.dep.type].
>> Thanks for discussing such an example.
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
>
> I agree that the current wording does not make "Test" a dependent type in your example. GCC/Clang/MSVC violate [temp.res]/10 by failing to give an undeclared-identifier error for "show".
>
> But maybe that's intentional, and it's the wording that needs to be changed. If nested classes in class templates are dependent, why not also local classes in function templates?


Thank you for your response. I agree with you. I think such local
class should be a dependent type. I think [temp.dep.type] should be
modified to cover this case. In addition, I think another example also
affected by such change. Please look at this
example(https://stackoverflow.com/questions/63515742/a-issue-about-the-second-phase-name-lookup-for-default-argument),
According to [temp.inst#11], that means the closure type as if it was
declared in the enclosing function scope. if such local closure type
is not be considered as dependent-type. How does the second phase name
lookup occur for such name? Like what I have pointed out in that
question, the latest gcc agree with that "zap" is not a dependent
name. It seems to not the intention of proposal resolution 1664.