C++ Logo


Advanced search

Re: Is the local class of function template be considered as dependent type

From: jim x <xmh970252187_at_[hidden]>
Date: Sat, 22 Aug 2020 14:29:19 +0800
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
for the example in the above
that would mean:
// pseudo code
void zip<long>(){ // a specialization for function template zip when
the template argument is `int`
  class local_closure_type{
      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
"therefore its associated namespaces – remain as determined from the
context of the definition for the default argument", namely `namespace

Received on 2020-08-22 01:32:57