<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/102725>102725</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
Disagreement Between clang and gcc on "Deducing this" Behavior
</td>
</tr>
<tr>
<th>Labels</th>
<td>
clang
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
Cfretz244
</td>
</tr>
</table>
<pre>
I was playing around with the new "deducing this" functionality in C++23, and found a case that `gcc` and `clang` disagree on, and my intuition is that `clang` handles it incorrectly. I've minimized the original code I was working on into the following example. Consider the following case:
```c++
#include <utility>
#include <type_traits>
struct foo {
int asdf;
template <class T, class O>
using conversion_type = std::conditional_t<
std::is_lvalue_reference_v<O>,
T&,
T
>;
template <class Self>
operator conversion_type<int, Self>(this Self&& self) {
return std::forward<Self>(self).asdf;
}
};
int main() {
foo f;
int& fdsa = f;
int&& asdf = std::move(f);
}
```
Without worrying too much about why on Earth I was doing this, I was trying to declare an implicit conversion operator that changes the value category of the type it converts TO based on the deduced value category of the object being converted FROM.
In this particular case, if the object to be converted is an lvalue, I'd like the conversion operator to resolve to converting to an lvalue reference to the subobject, and if not, I'd like it to resolve to converting to a temporary (not an rvalue reference, I'd like it to instead move the subobject into a new temporary).
`gcc` is entirely willing to compile this code, and it appears to work as I was expecting. `clang` will compile the third line inside of main, but will not compile the second, claiming that `non-const lvalue reference to type 'int' cannot bind to a value of unrelated type 'foo'`, which sounds to me like it's not even considering the conversion operator.
Given the fact that `clang` appears to be inconsistent in its handling of this, I assume this is likely a `clang` bug, but I am not an expert on the standard and could be wrong.
Here's a link to compiler explorer that demonstrates the issue: https://godbolt.org/z/dG6jTj9rr
If you switch the compiler to any version of gcc 14, it will build without issues. Thoughts?
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJx8Vk2P4jgQ_TXmUhoEDk3gwGGaHmb7sBppt6U9thy7knjGsZFdgWF-_aqc8Dm9i1o0iV3P9erVh1VKtvGIG_H0LJ5eJqqnNsTNto5Iv-RiMamCOW1e4agS7J06Wd-AiqH3Bo6WWqAWweMRhJQGTa95nVqbhJRQ916TDV45SyewHrZCPgv5LAsht6C8gToDKdAqIVCrCMRy1mgtlrO8LpYz7ZRv-NnYpJqICMGfzTtGpd7yIWDTBeFi0ypvHCawBNbrECNqcqcpvApZHhA6621nf6HJNEK0jfXKgQ4GYaB8DPEHU2J8TyHvq4Nz4chv8afq9g6nsA0-WYPxYZ1pieKzmL2I2fl7ORv-9BCL8a0srNeuNwii2PZkOWKi-PLRKp32-E5RWUrXHfk7Uew1QR0CiHJEBgD2HFQytSieb7fzEmG3d4oysHYqJXjj4A4_v13weWufMqXgDxiTDf6dHQFRvEAiwyyLzzp4YwfF30kU29H4sm7Tuzso1-N7xBojeo3vB1Fs80Fyez2LP29CLj94eXlkmwdCv7P5G119xyLsMSoK8ZGIKLbWE3M_m8gV5_HwyJ4sIeWf6_vg8ici9dFfedYhHlU0othewUbj6Z0QIMqXkUH58sCGVeuU9UKufjuUJb5BGTRmF2uTVNbko1XewMffi9aFAwq5YueuHlzcOqfrrWf_WGpDT1wcMTcECgG6Xregqvy-PXHBfFGR2rGOTLg2hu34js7GYFA7FRGUB9vtndWWbvS5apbrW7fKN5hyqeVkAq0ImxBPEOr8NifmBYISvH2DSiU07BVvyJ0KzX-Yh-o7aoIKr_lOaGD317c_p7dhePWZEOxVJKt7p-JQ8HIL9g6JAlR4g2QTMx0qIYdDyNKAsz8wW33IPEDEFNwB-ecINUbvggWXqoKxVaW-Gnw4d0xbgw_0cKil_8fPdRWiiicQcuUD8ZHx4cgPMa1PhMoA59i9Q0M7VXl2XOC5Ph6a5TgMbAL0ZCO6Exytc6NrOnR763DQgdv2hSeB2u9RxcTbuIuDSmPe4c89aiY3vZsVDHsDmEEjs_HIPKxBTpChIrdQcZ6zBYfj1iohd8GxidpuSPthLPngP-ngE32sV26nssy1WoJWnqEr680gwmASauh9RO5y5mJShyBkyVUqt3BsrW4h8WTN5Ds8KyJkmbK_eEDPIueZNXj4YdrdifHVslUecIqT-nHW3sS7wjxufbKJ0LPWYCkN0zhP0_qmFaiU-m6U0KbsqzuBusOu-uYc9FdQHYw5yEpGOld1IuWNiiYngA69M-zIMQbf3BH5AyPmUCgW98dNHkVGdCHi2GoMdixXVDT2G5tSzxMdWqJ94v4pd0LummCq4GgaYiPk7peQO_N1-f3t-zrGu4ZRwyn0kI6WdDvGfDw3l_EJLgLU0GgN80VuJmOmVb11w62Lm2x2JU3hrQ190_JdYDcxm8Ksi7Wa4GZeykIu1-v1YtJu5qv5elWVeo3LRYmlLLFcruTTU2VwvqgRJ3YjZ3IxW81ns-VsWSymM7nA-QJLXNZPuDBzsZhhp6ybOnfomOckn7-Zz2QpnyZOVehSvkNKOagmJV8n44YNPlV9k8Ri5myidIUgSw43L-O9ruNMeUY6IicnY2QhOQ7B8_3y5fF--YytOtgQJ310mwdFLLV9NdWhE3LHB47_Pu1jGPrhbgigkLuRw2Ej_w0AAP__3jWWhQ">