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.

Sign up for GitHub

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

Jump to bottom

The range of the application of [namespace.udecl#11] #4590

Open
xmh0511 opened this issue Apr 22, 2021 · 3 comments
Open

The range of the application of [namespace.udecl#11] #4590

xmh0511 opened this issue Apr 22, 2021 · 3 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 22, 2021 •
edited

The set of declarations named by a using-declarator that inhabits a class C does not include member functions and member function templates of a base class that correspond to (and thus would conflict with) a declaration of a function or function template in C.

See the following example

struct Base{
    static void fun(){}
};
struct D:Base{
    using Base::fun;
    // decltype(fun()) a;  //#1
    // static auto fun()->decltype(fun()){return 0;}  //#2
    static int fun(){
        return 0;
    }
    decltype(fun()) a;  //#3
};

#1 and #2 are both ill-formed considered by the major implementations. Instead, #3 is ok. It seems that the bullet [namespace.udecl#11] does not uniformly apply to any case. It appears to me that the declarations named by using-declaration are being hidden from the point P which is immediately after the locus of the declarations that is declared in C.

Should we say

After a point P, the set of declarations named by a using-declarator that inhabits a class C does not include member functions and member function templates of a base class that correspond to (and thus would conflict with) a declaration of a function or function template in C where P is immediately after the locus of the declaration.
@jensmaurer
Copy link
Member

This is a larger "order of parsing class definitions" problem. We only know whether the using-declaration makes some function name visible after we've parsed the rest of class, to know which functions conflict. In the extreme, whether or not there is a conflict can depend on whether or not a using-declaration was in effect.

This is certainly not an editorial matter. CWG1890 looks related.

@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. labels Apr 22, 2021
@xmh0511
Copy link
Contributor Author

xmh0511 commented Apr 23, 2021 •
edited

This is a larger "order of parsing class definitions" problem. We only know whether the using-declaration makes some function name visible after we've parsed the rest of class, to know which functions conflict. In the extreme, whether or not there is a conflict can depend on whether or not a using-declaration was in effect.

This is certainly not an editorial matter. CWG1890 looks related.

I think that the name lookup for a using-declaration might be performed each time whenever a potential conflict declaration is encountered in the subsequent in order to exclude the declaration from the set which potentially conflicts with that. So, we should define the range of the application of bullet [namespace.udecl#11]. That conforms with the following rule:

In general, whenever a name is encountered it is necessary to determine whether that name denotes one of these entities before continuing to parse the program that contains it. The process that determines this is called name lookup ([basic.lookup]).

And violent agree that this issue should be considered CWG.

@jensmaurer
Copy link
Member

jensmaurer commented Apr 23, 2021 •
edited

[class.member.lookup] p6 says

If it differs from the result of a search in T for N from immediately after the class-specifier of T , the program is ill-formed, no diagnostic required.

Your cases #1 and #2 are ill-formed because of this rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
Milestone
No milestone
Development

No branches or pull requests
2 participants
@xmh0511 @jensmaurer