[dcl.fct.def.default] This can't apply to constructors as they don't have type

[ranaanoop]

Full name of submitter: Anoop Rana

Reference (section label): [dcl.fct.def.default]

Issue description:

The following program seem to be well-formed as per current standard wording as explained below. But only EDG accepts it while gcc,clang and msvc rejects it. Demo.

struct C
{
   C(const C&&) = default; // EDG: ok, gcc: No, Clang: No
};
int main()
{
    
}

The explanation for why this seems to be well-formed is as following.

First note that C::C(const C&&) is a move ctor as per class.ctor:

A non-template constructor for class X is a move constructor if its first parameter is of type X&&, const X&&, volatile X&&, or const volatile X&&, and either there are no other parameters or else all other parameters have default arguments ([dcl.fct.default]).

Now we move onto dcl.fct.def.default where we see the condition for a function to be defaulted.

A function definition whose function-body is of the form = default ; is called an explicitly-defaulted definition.A function that is explicitly defaulted shall:

• be a special member function[special] or a comparison operator function ([over.binary], [class.compare.default]), and

This means that if C(const C&&) = default; is either a a special member function or a comparison operator function then the program will be valid.

So we move onto special:

Default constructors ([class.default.ctor]), copy constructors,move constructors,copy assignment operators, move assignment operators ([class.copy.assign]), and prospective destructors ([class.dtor])are special member functions.

The above means that the move constructor C::C(const C&&)= default; is a special member function. Thus it can be defaulted and so the program is well-formed.

Now we move onto dcl.fct.def.default:

An explicitly defaulted special member function F1 is allowed to differ from the corresponding special member function F2 that would have been implicitly declared, as follows:

• F1 and F2 may have differing ref-qualifiers;
• if F2 has an implicit object parameter of type “reference to C”, F1 may be an explicit object member function whose explicit object parameter is of (possibly different) type “reference to C”, in which case the type of F1 would differ from the type of F2 in that the type of F1 has an additional parameter;
• F1 and F2 may have differing exception specifications; and
• if F2 has a non-object parameter of type const C&, the corresponding non-object parameter of F1 may be of type C&.

If the type of F1 differs from the type of F2 in a way other than as allowed by the preceding rules, then:

• if F1 is an assignment operator, and the return type of F1 differs from the return type of F2 or F1's non-object parameter type is not a reference, the program is ill-formed;
• otherwise, if F1 is explicitly defaulted on its first declaration, it is defined as deleted;
• otherwise, the program is ill-formed.

As you can see dcl.fct.def.default#2.6 makes F1 deleted which means the program is well-formed.

But note the emphasis on the phrase "type of F1" and "type of F2" in dcl.fct.def.default#2.2. But in case F1 and F2 are ctors, what will the type of constructor mean as we know that constructors don't have type in C++. So how can this part of the above clause where the terms "type of F1" and "type of F2" is used supposed to be applicable to constructors. We need to define the meaning of type of a constructor.

[t3nsor]

Technically, constructors do have types per [dcl.fct]. The type of the constructor in your example is "function of (const C&&)" (with no return type). You just can't observe this type from within the language.

As such, the wording is clear that this example falls under [dcl.fct.def.default]/2.6 and you should file bug reports for the implementations that reject it.

[ranaanoop]

@t3nsor No as per this, constructors don't have types. So the wording is not clear.

[t3nsor]

The linked answer does not substantiate its claim that constructors lack types. It points out that the type of a constructor cannot be "examined" by a program, which is similar to what I said above. However, [dcl.fct] is clear that a function declarator gives a function type to the entity so declared.

[ranaanoop]

@t3nsor The linked answer does say that ctor don't have type as opposed to your claim that the answer doesn't. In particular, it says:

Therefore the standard doesn't specify a "type" for constructors...

[languagelawyer]

@ranaanoop «StoryTeller - Unslander Monica» is well known for drawing weird conclusions, not sure why u r preferring his unfounded words to clear Standard wording

[t3nsor]

@t3nsor The linked answer does say that ctor don't have type as opposed to your claim that the answer doesn't. In particular, it says:

Therefore the standard doesn't specify a "type" for constructors...

I think you might be having trouble understanding English. As I pointed out in my previous reply:

The linked answer does not substantiate its claim that constructors lack types

In other words, I acknowledge that the answer does make the claim that constructors lack types, but it fails to substantiate that claim.

[ranaanoop]

@t3nsor Neither do you substantiate your claim. Your claim that ctors have a type is no different than the claim in that answer. Worse, you claim is technically wrong as explained below. Btw here is another question where answers explain that ctors don't have type. But the answers there too aren't complete.

Here's why I think ctors don't have type.

This can be seen from dcl.fct:

1. In a declaration T D where D has the form

 D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
   ref-qualifieropt noexcept-specifieropt attribute-specifier-seqopt

2. In a declaration T D where D has the form

 D1 ( parameter-declaration-clause ) cv-qualifier-seqopt
   ref-qualifieropt noexcept-specifieropt attribute-specifier-seqopt trailing-return-type  

3. A type of either form is a function type.

(emphasis mine)

The above means that say int(int) or auto(int)const->int is a function-type but (const C&&) isn't. It has no T as the return type and so it is neither of the form mentioned in the above quoted reference. Instead constructor form is governed by ctor.general which isn't a function-type I'll add this as an answer there to complete that question.

[t3nsor]

[dcl.fct]/1 is clear that "T may be empty", which is the case in a constructor declaration, therefore, a constructor declaration does have the form described in [dcl.fct]/1. [dcl.fct] also explains how to determine the type of an entity that is declared using a function declarator.

[ranaanoop]

@t3nsor In C++20, T can't be empty as per dcl.fct but in C++23 it can be. So the behavior seems to be changed from C++20 to C++23. Was this change intentional?

[t3nsor]

Presumably it was always intended to let T be empty, otherwise constructors would not fall under [dcl.fct] at all, and it would be impossible to understand how to interpret constructor declarations.

The wording change was effected by CWG2476.

[ranaanoop]

@t3nsor So the status is DRWP. Does this mean it will apply as DR to C++20 also? I've added an answer.

[t3nsor]

DRWP status means that it's not in C++23 but is in the C++26 working draft. The DR nature of an issue resolution technically doesn't have normative force, and is a recommendation that the resolution be considered retroactive to whatever earlier versions of the standard it can sensibly apply to. In this particular case, because it was always the intent of the Standard that it is possible to declare constructors at all, the allowance for T to be empty can be considered to be retroactive to C++98.

[ranaanoop]

@t3nsor I see. So as published C++23 do not allow ctor to have a type. But through [CWG2479] whose status is DRWP, constructors do have type. I've mentioned it in my answer. Thanks for the CWG I wasn't aware of that CWG. So during this whole discussion, I only looked at the c++23 draft.

[jensmaurer]

So, the end result is that there is no issue in the current Working Draft.

Thanks @t3nsor for saving me the lengthy discussion here.