[llvm-bugs] [Bug 51763] New: Two type that are not reference-related can further converted in reference initialization

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51763

            Bug ID: 51763
           Summary: Two type that are not reference-related can further
                    converted in reference initialization
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++2a
          Assignee: unassignedclangbugs at nondot.org
          Reporter: xmh970252187 at gmail.com
                CC: blitzrakete at gmail.com, erik.pilkington at gmail.com,
                    llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk

char cc;
struct A{
    operator char&(){
        return cc;
    }
};
int main(){
   A a;
   int&& rf = a;
}

Clang rejects this example while GCC accepts it. GCC has a correct
interpretation for this example, since [dcl.init.ref#5.4.1] make `A::operator
char&()` be a candidate to convert the original initializer expression `a`,
which brings it to type `char`, as per [dcl.init.ref#5.4.1]    

> 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.  

It means the effect would be the same as that `int&& rf(a.operator char&())`,
since their types are not reference-related, [dcl.init.ref#5.4.2] can apply to
it to do the further conversion, which converts the result of `a.operator
char&()` to type `T`, no user-defined conversion is applied, hence the whole
reference initialization would like to be that `int&&
rf(static_cast<int>(a.operator char&()))`.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210906/2ff22b99/attachment.html>