CWG2714 [over.match.class.deduct] implicit deduction guide wording does not inherit important properties from the parameter-declaration-clause of a constructor

[zygoloid]

Reference (section label): [over.match.class.deduct]

Link to reflector thread (if any): https://lists.isocpp.org/core/2017/02/1752.php

Issue description:

[over.match.class.deduct]/1.1.2 says:

The types of the function parameters are those of the constructor.

... but does not say that default arguments are inherited, and likewise does not say that the deduction guide is variadic if the constructor is variadic.

Similar issues arise with constraints on the constructor.

Suggested resolution:

Change in [over.match.class.deduct]/1:

[...]

• If C is defined, for each constructor of C, a function template with the following properties:
  - The template parameters are the template parameters of C followed by the template parameters (including default template arguments) of the constructor, if any.
  - The associated constraints are the associated constraints of C followed by the associated constraints of the constructor, if any. [Note: A constraint-expression in the template-head of C is checked for satisfaction before any constraints from the template-head or trailing-requires-clause of the constructor.]
  - The types of the function parameters are those parameter-declaration-clause is that of the constructor.
• [...]
• For each deduction-guide, a function or function template with the following properties:
  - The explicit-specifier and template parameters template-head, if any, and function parameters parameter-declaration-clause are those of the deduction-guide.
  - The return type is the simple-template-id of the deduction-guide.

Aside: should deduction-guides allow a trailing requires-clause? (GCC and MSVC allow this; Clang and the grammar do not.)

[jensmaurer]

CWG2628 deals with constraints from the constructor, but your wording is more comprehensive. Instead of "followed by", I'd like to use "conjunction", though, for the associated constraints.

[jensmaurer]

CWG2714

[jensmaurer]

@zygoloid , I think deduction guides are described as creating free functions / function templates. How can an explicit-specifier appear with these?

[zygoloid]

Hm, we convert constructors and deduction guides into functions ("guides", which are presumably not constructors, though we don't seem to say that) and then convert those functions back into constructors later, which is a little odd -- and appears to say that we form constructors with return types, which seems wrong. It looks like the conversion from guides to constructors does add back explicit already so maybe that part is OK already, and it's just the parameter-declaration-clause and constraints that aren't handled.

[jensmaurer]

I've amended CWG2714 to refer to associated constraints and template-heads only; the explicit-specifier appears to be handled in sentence you refer to. As it stands, the issue and the proposed resolution are nicely scoped and self-contained, so I'd like to go forward with that as a first step.

[jensmaurer]

should deduction-guides allow a trailing requires-clause?

The grammar in [temp.deduct.guide] seems clear that a trailing requires-clause is not allowed. Is there an example or rationale in the original "deduction guides" paper that would imply this isi an oversight? I'm sure a one-page paper to EWG, citing existing implementation experience, would fly through.

[zygoloid]

Is there an example or rationale in the original "deduction guides" paper that would imply this is an oversight?

The timeline doesn't really allow that to have happened directly. The original paper that added syntax for deduction-guides was merged in C++17, and concepts weren't added to the IS until C++20 (they were added to the draft only one meeting later, I think, but still). On the other hand, the Concepts TS added the language syntax for requires-clauses and predates class template argument deduction by a couple of years. :)

However, we do have indirect evidence. P0091R3 section "Explicitly specified Deduction Guides" says

this allows users to leverage all the deduction rules that are specifiable by any function

and the "Alternate notation" section reinforces (but doesn't explicitly state) that the design is to use the syntax of a function / function template with a trailing-return-type but no type-specifier -- and indeed I believe that is how the syntax was described when presented to EWG.