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{})".