Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When does the lookup perform for a name used in default member initialization in a class template CWG1396 #4585

Open
xmh0511 opened this issue Apr 16, 2021 · 6 comments
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Apr 16, 2021

This is also an issue that I recently asked on SO(https://stackoverflow.com/questions/67086569/how-does-the-lookup-rule-apply-to-a-name-that-is-used-in-a-default-member-initia). It seems no one can use the current wording to interpret this issue. In simple, the issue is:

#include <iostream>
template<class T>
struct A{
    int c = T::a;
};
struct B{
    A<B> cc;
    static const int a = 0;
};
int main(){

}

The definition of cc would cause the implicit specialization for A<B>, which in turn would cause the name lookup for T::a.

The declaration set is the result of a single search in the scope of C for N from immediately after the class-specifier of C if P is in a complete-class context of C or from P otherwise. If the resulting declaration set is not empty, the subobject set contains C itself, and calculation is complete.

According to the above code, we consider the P is not in the complete context of B, hence the member a of B cannot be found at this point. However, major implementations all accept the above example(GCC and Clang). The relevant rule of performing the lookup for a dependent name that appears in template entity is defined as:

If the name is dependent (as specified in [temp.dep]), it is looked up for each specialization (after substitution) because the lookup depends on a template parameter.

It's vague here. I infer that the name lookup for T::a might be in the definition context of the constructor of the specialization of template class A. such that could interpret the behavior of these compilers. This is hinted at in the following rule:
[class.base.init#9]

In a non-delegating constructor, if a given potentially constructed subobject is not designated by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer), then

if the entity is a non-static data member that has a default member initializer ([class.mem]) and either
the entity is initialized from its default member initializer as specified in [dcl.init];

However, it's not explicit. I think we should give an explicit rule for when does the name lookup perform for the name in such a case.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Apr 21, 2021
@jensmaurer
Copy link
Member

I think we should give default member initializers "when needed" treatment, similar to noexcept-specifiers or default function arguments [temp.inst] p12, p14.

However, that feels non-editorial.

@languagelawyer
Copy link
Contributor

I think we should give default member initializers "when needed" treatment, similar to noexcept-specifiers or default function arguments

The same is written in https://wg21.link/cwg1396

@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 22, 2021

I think we should give default member initializers "when needed" treatment, similar to noexcept-specifiers or default function arguments

The same is written in https://wg21.link/cwg1396

Yes, CWG has agreed to such a proposal. We may change [temp.spec#temp.inst-3] to

The implicit instantiation of a class template specialization does not cause the implicit instantiation of default arguments or noexcept-specifiers of the class member functions and the implicit instantiation of the default member initializer.

Add a new bullet for default member initializer into [temp.inst] as the same manner as [temp.inst#12] has done.

@jensmaurer jensmaurer changed the title When does the lookup perform for a name used in default member initialization in a class template When does the lookup perform for a name used in default member initialization in a class template CWG1396 Apr 22, 2021
@jensmaurer jensmaurer added cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Apr 22, 2021
@jensmaurer
Copy link
Member

Since there is an open core issue covering that matter, this shouldn't be handled editorially.

@frederick-vs-ja
Copy link
Contributor

Seems to be fixed by #5987 (47a1382).

@xmh0511
Copy link
Contributor Author

xmh0511 commented Aug 21, 2023

Seems to be fixed by #5987 (47a1382).

#5987 is about the default argument rather than default member initialization, this issue is about the name lookup in the default member initialization of a specialization of a class template whose template argument is a class where the instantiation occurs in the non-complete class context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG. not-editorial Issue is not deemed editorial; the editorial issue is kept open for tracking.
Projects
None yet
Development

No branches or pull requests

4 participants