Skip to content

P2533R0 Core Language Working Group "ready" #5287

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

Merged
tkoeppe merged 7 commits into from
Feb 16, 2022
Merged

P2533R0 Core Language Working Group "ready" #5287

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
e7fb089
CWG1726 Declarator operators and conversion function
jensmaurer Feb 10, 2022
a53083b
CWG2494 Multiple definitions of non-odr-used entities
jensmaurer Feb 15, 2022
bd7606c
CWG2499 Inconsistency in definition of pointer-interconvertibility
jensmaurer Feb 10, 2022
d2c8bd8
CWG2502 Unintended declaration conflicts in nested statement scopes
jensmaurer Feb 10, 2022
dc697e5
CWG2506 Structured bindings and array cv-qualifiers
jensmaurer Feb 10, 2022
0fbb2f2
CWG2509 decl-specifier-seq in lambda-specifiers
jensmaurer Feb 10, 2022
e941a31
CWG2511 cv-qualified bit-fields
jensmaurer Feb 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 42 additions & 10 deletions source/classes.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2472,8 +2472,6 @@
\indextext{fundamental type conversion|see{conversion, user-defined}}%
\indextext{conversion!user-defined}%

\pnum
A member function of a class \tcode{X} with a name of the form
\begin{bnf}
\nontermdef{conversion-function-id}\br
\keyword{operator} conversion-type-id
Expand All @@ -2488,18 +2486,52 @@
\nontermdef{conversion-declarator}\br
ptr-operator \opt{conversion-declarator}
\end{bnf}
shall have no non-object parameters and
specifies a conversion from \tcode{X} to

\pnum
A declaration
whose \grammarterm{declarator-id} has
an \grammarterm{unqualified-id} that is a \grammarterm{conversion-function-id}
declares a \defnadj{conversion}{function};
its \grammarterm{declarator} shall be
a function declarator\iref{dcl.fct} of the form
\begin{ncsimplebnf}
ptr-declarator \terminal{(} parameter-declaration-clause \terminal{)} \opt{cv-qualifier-seq}\br
Comment thread
tkoeppe marked this conversation as resolved.
Resolved
\bnfindent \opt{ref-qualifier-seq} \opt{noexcept-specifier} \opt{attribute-specifier-seq}
\end{ncsimplebnf}
where the \grammarterm{ptr-declarator} consists solely of
an \grammarterm{id-expression},
an optional \grammarterm{attribute-specifier-seq}, and
optional surrounding parentheses, and
the \grammarterm{id-expression} has one of the following forms:
\begin{itemize}
\item
in a \grammarterm{member-declaration} that belongs to
the \grammarterm{member-specification} of a class or class template
but is not a friend declaration\iref{class.friend},
the \grammarterm{id-expression} is a \grammarterm{conversion-function-id};
\item
otherwise, the \grammarterm{id-expression} is a \grammarterm{qualified-id}
whose \grammarterm{unqualified-id} is a \grammarterm{conversion-function-id}.
\end{itemize}

\pnum
A conversion function shall have no non-object parameters and

@JohelEGP JohelEGP Feb 22, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core issue doesn't include "non-object".

I suppose you added it to account for explicit object parameters.

Is that really enough? No need to restrict it to an explicit object parameter, but any amount of non-object parameters is OK? Is there wording elsewhere that make these cases ill-formed, and thus saying "non-object" is enough?

How about the function type specified below? Does it need a revision, too?

@tkoeppe tkoeppe Feb 22, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the paper misrepresents the status quo? So tihs seems like a "plausible merge".

@jensmaurer jensmaurer Feb 22, 2022

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A conversion function with an explicit this parameter seems plausible, but there must not be other parameters. Further cleanup (if any) should be in a separate editorial or core issue.

shall be a non-static member function of a class or class template \tcode{X};
it specifies a conversion from \tcode{X} to
the type specified by the \grammarterm{conversion-type-id},
interpreted as a \grammarterm{type-id}\iref{dcl.name}.
Such functions are called \defnx{conversion functions}{conversion function}.
A \grammarterm{decl-specifier} in the \grammarterm{decl-specifier-seq}
of a conversion function (if any) shall be neither
a \grammarterm{defining-type-specifier} nor \keyword{static}.
of a conversion function (if any) shall not be
a \grammarterm{defining-type-specifier}.

\pnum
\indextext{conversion!type of}%
The type of the conversion function\iref{dcl.fct} is
``function taking no parameter returning
\grammarterm{conversion-type-id}''.
The type of the conversion function is
``\opt{\tcode{noexcept}} function taking no parameter
\opt{\grammarterm{cv-qualifier-seq}} \opt{\grammarterm{ref-qualifier}}
returning \grammarterm{conversion-type-id}''.

\pnum
A conversion function is never used to convert a (possibly cv-qualified) object
to the (possibly cv-qualified) same object type (or a reference to it),
to a (possibly cv-qualified) base class of that type (or a reference to it),
Expand Down