| Issue |
155962
|
| Summary |
[libc++] Hard errors caused by narrowing conversions in list-initialization are suppressed
|
| Labels |
libc++,
accepts-invalid
|
| Assignees |
|
| Reporter |
frederick-vs-ja
|
Conversions functions of `ranges` algorithm result types are specified to copy-list-initialize the results ([[algorithms.results]](https://eel.is/c++draft/algorithms.results)).
As a result, narrowing conversions should cause hard errors in the functions. However, Clang seems to suppress the errors due to `#pragma GCC system_header`. [Godbolt link](https://godbolt.org/z/6o4av1z8K).
```C++
#include <algorithm>
#include <concepts>
template <class I1>
struct my_in_found_result {
[[no_unique_address]] I1 in;
bool found;
template <class I2>
requires std::convertible_to<const I1&, I2>
constexpr operator my_in_found_result<I2>() const& {
return {in, found};
}
template <class I2>
requires std::convertible_to<I1, I2>
constexpr operator my_in_found_result<I2>() && {
return {std::move(in), found};
}
};
int main(int, char**) {
{
std::ranges::in_found_result<double> res{10, true};
std::ranges::in_found_result<int> res2 [[maybe_unused]] = res; // hard error suppressed
}
{
my_in_found_result<double> res{10, true};
my_in_found_result<int> res2 [[maybe_unused]] = res; // correctly rejected
}
}
```
Although it might deserve an LWG issue to fix the constraints, i.e. either accept narrowing conversions by not using list-initialization, or constrain harder to reject narrowing conversions in an SFINAE-friendly way, it seems to me that we shouldn't suppress `-Wc++11-narrowing` in standard library headers.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
