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

[dcl.init.ref] instructs performing direct initialization after applying a user-defined conversion #4274

Open
RazvanAM opened this issue Oct 2, 2020 · 2 comments
Open

[dcl.init.ref] instructs performing direct initialization after applying a user-defined conversion #4274

RazvanAM opened this issue Oct 2, 2020 · 2 comments
Labels
cwg Issue must be reviewed by CWG.

Comments

@RazvanAM
Copy link

RazvanAM commented Oct 2, 2020

[dcl.init.ref] paragraph 5, bullet 4, sub-bullet 1 specifies the following:

If T1 or T2 is a class type and T1 is not reference-related to T2, user-defined conversions are
considered using the rules for copy-initialization of an object of type “cv1 T1” by user-defined
conversion (9.4, 12.4.1.4, 12.4.1.5); the program is ill-formed if the corresponding non-reference
copy-initialization would be ill-formed. The result of the call to the conversion function, as
described for the non-reference copy-initialization, is then used to direct-initialize the reference.
For this direct-initialization, user-defined conversions are not considered.

The highlighted wording (which requires performing direct initialization after applying the user-defined conversion) was added in CWG1604. Given that "user-defined conversions are not considered" for the next step of the initialization, I believe that requiring a specific type of initialization does not have any effect on the outcome.

I think there is another issue with the quoted text above, namely:

[...] The result of the call to the conversion function [...]

I believe that the user-defined conversion referred to here could use either a converting constructor or a conversion function, not just a conversion function.

Thank you!
@RazvanAM
Copy link
Author

RazvanAM commented Oct 3, 2020 •
edited

Also, the last sentence from the quoted text:
[...] For this direct-initialization, user-defined conversions are not considered.
seems to be superfluous, as the type that results from [over.match.copy] or [over.match.conv] (henceforth referred to as T3) is:

  • T1 or a type derived from T1 (in case T1 is a class type; [over.match.copy]), or
  • T1 or a type that can be converted to T1 using a standard conversion sequence (in case T1 is not a class type; [over.match.conv])

Only the first case (T1 is a class type) is of interest (otherwise user-defined conversions are excluded by default in the second stage of the initialization). T3 is reference-related to T1, and [dcl.init.ref] paragraph 5 only considers user-defined conversions in case the reference type and the initializer type are not reference-related. Therefore explicitly disallowing user-defined conversions in the second stage of the reference initialization is not required.

I believe the restriction was unnecessary even considering the state of the standard when the resolution for CWG1604 was proposed (the resolution for CWG1604 added this restriction).

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Jan 3, 2021
@jensmaurer
Copy link
Member

Editorial meeting 2021-04-30: Send to CWG.

@jensmaurer jensmaurer added cwg Issue must be reviewed by CWG. and removed decision-required A decision of the editorial group (or the Project Editor) is required. labels Apr 30, 2021
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.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@RazvanAM @jensmaurer