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

Improve [dcl.fct.def.general] p2 #5184

Open
xmh0511 opened this issue Jan 5, 2022 · 1 comment
Open

Improve [dcl.fct.def.general] p2 #5184

xmh0511 opened this issue Jan 5, 2022 · 1 comment

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Jan 5, 2022

[dcl.fct.def.general] p2

The type of a parameter or the return type for a function definition shall not be a (possibly cv-qualified) class type that is incomplete or abstract within the function body unless the function is deleted ([dcl.fct.def.delete]).

Consider these examples

Example 1:

struct C;
template<class T>
struct D{
    auto show(){
        return reinterpret_cast<C&&>((int&&)0);  // ignore the UB here
    }
};

Example 2:

struct C;
struct D{
    template<class T>
    T show(){
        return reinterpret_cast<C&&>((int&&)0);  // ignore the UB here
    }
};

Example 3:

struct C;
struct D{
    template<class T>
    C show(){
        return T{};
    }
};

Example 4:

struct C;
struct D{
    auto show(){
        return reinterpret_cast<C&&>((int&&)0);  // ignore the UB here
    }
};

The first two examples are accepted by both GCC and Clang. Conversely, the last two are rejected by both of them. It seems [dcl.fct.def.general] p2 didn't cover the templated entity case where the return type or parameter types are placeholder types or dependent types. The modification is that:

If the function definition is not for a templated function:

  • the type of a parameter or the return type(possibly deduced from placeholder type deduction) shall not be a (possibly cv-qualified) class type that is incomplete or abstract within the function body unless the function is deleted.

Otherwise

if the type is a placeholder type or a dependent type:

  • the type shall not be a (possibly cv-qualified) class type that is incomplete or abstract at the point of instantiation unless the function is deleted.

Otherwise

  • the type shall not be a (possibly cv-qualified) class type that is incomplete or abstract within the function body at the definition context unless the function is deleted.
@jensmaurer
Copy link
Member

In general, the original rule is needed because we need complete types when generating machine code for a function definition. So, it only applies to fully-instantiated function definitions. I agree the current phrasing is a bit ambiguous.

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

2 participants