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

Unclearly defined rule in [over.match.funcs#general-5] conflicts with the rule defined in [dcl.init.ref#5.2] #4751

Open
xmh0511 opened this issue Jul 15, 2021 · 2 comments
Labels
cwg Issue must be reviewed by CWG.

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Jul 15, 2021

struct A{
    A() = default;
    A(volatile const A&){}
    void show()const volatile {}  // its implicit object parameter is of type volatile const A&
};
volatile A a;
A b = std::move(a);  //1 ill-formed
std::move(a).show(); //2 ok

Since prescribed in [dcl.init.ref#5.2]

Otherwise, if the reference is an lvalue reference to a type that is not const-qualified or is volatile-qualified, the program is ill-formed.

"//1" is definitely ill-formed. However, according to [over.match.funcs#general-4], the implicit object parameter should be volatile const A&, the parameter type is basically the same as that of "//1" chosen. Presumably,[over.match.funcs#general-5] gives the privilege, that is

For non-static member functions declared without a ref-qualifier, even if the implicit object parameter is not const-qualified, an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter.

Since there is not an exception expound in [dcl.init.ref#5.2], it appears to me that the conflict would be resulted in by [over.best.ics#general-1], that is

The sequence of conversions is an implicit conversion as defined in [conv], which means it is governed by the rules for initialization of an object or reference by a single expression ([dcl.init], [dcl.init.ref]).

My proposal is that we should first change [dcl.init.ref#5.2] to that

Otherwise, if the reference is an lvalue reference to a type that is not const-qualified or is volatile-qualified, unless somewhere specified, the program is ill-formed.

Back to [over.match.funcs#general-5], I think that the expound "in all other respects" is unclear, I think it should be modified as the following so that will be more clear

For non-static member functions declared without a ref-qualifier, even if the implicit object parameter is not const-qualified or is volatile-qualified, or both, an rvalue can be bound to the parameter as long as their referenced types are reference-compatible.

In terms of the original [over.match.funcs#general-5], for instance

struct Test{
    void show(){}
};
Test const t;
std::move(t).show(); // ill-formed

It is not fine for explaining this example.

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

jensmaurer commented Jul 15, 2021

It's not clear to me what the standard's intent is here, and/or whether compilers implement that presumed intent.

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jul 16, 2021

How do you read it "as long as in all other respects the argument can be converted to the type of the implicit object parameter"? For this special case, we just skip [dcl.init.ref#5.2] and go into these next bullets, Is that your interpretation? If it were said, "even if the implicit object parameter is not const-qualified" is not sufficient, we should also mention "is volatile-qualified" to make the whole [dcl.init.ref#5.2] be skipped in this special case.

In addition, "the implicit object parameter is not const-qualified" sounds a bit strange, the type of the implicit object parameter is a reference, a reference cannot be cv-qualified. Should we say that

the reference type of the implicit object parameter is not const-qualified or is volatile-qualified

@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 Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG.
Projects
None yet
Development

No branches or pull requests

2 participants