[all-commits] [llvm/llvm-project] f80bd9: [Sema][CTAD] Allow user defined conversion for cop...

[Gábor Spaits via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f80bd9b8a8103f39f5fece019abf86d41098cec1
      https://github.com/llvm/llvm-project/commit/f80bd9b8a8103f39f5fece019abf86d41098cec1
  Author: Gábor Spaits <gaborspaits1 at gmail.com>
  Date:   2024-06-18 (Tue, 18 Jun 2024)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/Sema/Initialization.h
    M clang/lib/Sema/SemaInit.cpp
    A clang/test/SemaCXX/ctad-copy-init-list-narrowing.cpp

  Log Message:
  -----------
  [Sema][CTAD] Allow user defined conversion for copy-list-initialization (#94752)

Fixes #62925.

The following code:
```cpp
#include <map>

int main() {
   std::map m1 = {std::pair{"foo", 2}, {"bar", 3}}; // guide #2
   std::map m2(m1.begin(), m1.end()); // guide #1
}
```
Is rejected by clang, but accepted by both gcc and msvc:
https://godbolt.org/z/6v4fvabb5 .

So basically CTAD with copy-list-initialization is rejected.

Note that this exact code is also used in a cppreference article:
https://en.cppreference.com/w/cpp/container/map/deduction_guides

I checked the C++11 and C++20 standard drafts to see whether suppressing
user conversion is the correct thing to do for user conversions. Based
on the standard I don't think that it is correct.

```
13.3.1.4 Copy-initialization of class by user-defined conversion [over.match.copy]
Under the conditions specified in 8.5, as part of a copy-initialization of an object of class type, a user-defined
conversion can be invoked to convert an initializer expression to the type of the object being initialized.
Overload resolution is used to select the user-defined conversion to be invoked
```
So we could use user defined conversions according to the standard.

```
If a narrowing conversion is required to initialize any of the elements, the
program is ill-formed.
```
We should not do narrowing.

```
In copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed.
```
We should not use explicit constructors.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications