Christopher Hallock <christopherhallock_at_[hidden]> 于2020年8月22日周六 上午3:41写道：
>
>
> On Fri, Aug 21, 2020 at 5:37 AM jim x <xmh970252187_at_[hidden]> wrote:
>>
>> 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.
>
>
> On the other hand, it feels wrong for "foo([]{})" to use 2nd-phase name lookup, and "foo(local_class{})" is more similar to that than to "foo(nested_class{})".


I will give a pseudo code in the following to convenient to let you
know what I thought. if I don't misunderstand this paragraph
[temp.inst#11]<https://timsong-cpp.github.io/cppwp/n4659/temp.inst#11>,
for the example in the above
link<https://stackoverflow.com/questions/63515742/a-issue-about-the-second-phase-name-lookup-for-default-argument>,
that would mean:
````
// pseudo code
void zip<long>(){ // a specialization for function template zip when
the template argument is `int`
  class local_closure_type{
    public:
      void operator()(){}
  };
  local_closure_type lambda_expression{};
  int parameter = zap(lambda_expression);
}
````
So, I argue here, whether `local_closure_type` here is considered as
dependent-type, It's different from the local class type in this
question(`Test`), because `Test` is the local class which declared in
function template definition. Here such local closure-type for
lambda-expression `[]{}` is declared in function template
specialization, that's a distinction. We're 100% sure a local class
type that declared in function template definition should be
considered as dependent-type. However such `local_closure_type` as
shown in the pseudo code , whether it's a dependent-type or not? I'm
not sure. If it's not a dependent-type, then as what you said the
second phase name lookup action shouldn't perform for `zap` due to
it's not a dependent name. Otherwise, if `local_closure_type` is
viewed as a dependent-type, that means `zap` will be considered as a
dependent name. And its declarations will be determined from the
result of second phase name lookup, which will be found in the
associated namespaces, that is said in
[temp.inst#11]<https://timsong-cpp.github.io/cppwp/n4659/temp.inst#11>,
"therefore its associated namespaces – remain as determined from the
context of the definition for the default argument", namely `namespace
J`.