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

[dcl.spec.auto.general] p13 What is a function whose return type is considered as undeduced? #664

Open
xmh0511 opened this issue Jan 3, 2025 · 3 comments

Comments

@xmh0511
Copy link

xmh0511 commented Jan 3, 2025

Full name of submitter (unless configured in github; will be published with the issue): Jim X

Consider this example

struct A{
    auto f(){
        g();
    }
    auto g(){}
};

The compiler says

use of 'auto A::g()' before deduction of 'auto'

The justification might be [dcl.spec.auto.general] p13. However, it's unclear what function whose return type is considered as undeduced.

Suggestion Resolution:

A function whose return type contains placeholder type at point P is considered undeduced if its definition is not reachable.

@xmh0511 xmh0511 changed the title [dcl.spec.auto.general] p13 What function whose return type is considered as undeduced? [dcl.spec.auto.general] p13 What is a function whose return type is considered as undeduced? Jan 3, 2025
@jensmaurer
Copy link
Member

This is the "complete class context" question, and how exactly (in which order) class bodies and member function bodies are parsed.

@xmh0511
Copy link
Author

xmh0511 commented Jan 6, 2025

This is the "complete class context" question, and how exactly (in which order) class bodies and member function bodies are parsed.

According to [class.mem.general] p8, the body of A::f is complete class context, and the name lookup finds the declaration from the class-specifier of A as per [class.member.lookup] p3. It is unclear whether the declaration found from the class-specifier is considered undeduced.

@frederick-vs-ja
Copy link

frederick-vs-ja commented Jan 7, 2025

It seems that this should be handled together with CWG1890.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants