https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835

David Friberg <davveston at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davveston at gmail dot com

--- Comment #19 from David Friberg <davveston at gmail dot com> ---
Note that this bug report was marked as suspended based on the resolution of
CWG 1518 (and the related DR 1630) in June 2015, but the resolution of both
these issue were since changed. Citing 1518:

> Additional note, October, 2015:
> 
> It has been suggested that **the resolution of issue 1630 went too**
> far in allowing use of explicit constructors for default initialization, 
> and that default initialization should be considered to model copy 
> initialization instead. The resolution of this issue would provide an
> opportunity to adjust that.

P0398R0 [1] describes the final resolution to CWG 1518, after which the
following example is arguably well-formed:

 struct tag_t {
     explicit constexpr tag_t() = default;  // #3
 };

 struct S {
     constexpr S() {}
     constexpr S(S const&) {}
     S& operator=(S const&) { return *this; }
     S& operator=(tag_t) { return *this; }     // #1
 };

 int main() {
     S s{};
     s = {};  // #2: GCC error: ambiguous overload for 'operator='
 }


as (at least from C++17) #1 is not a viable overload for the assignment at #2,
as tag_t is not an aggregate and copy-list-init from empty braces will not
consider the ctor #3 as it is explicit.

The example above is rejected by GCC (various versions) for both C++17 and
C++20, whereas Clang and MSVC both accepts it (curiosly Clang accepts it also
for C++11 for C++14, which may be wrong as tag_t is an aggregate for these
case, but I'm unsure, as we are covering a lot of CWG/LWG/DR confusion for this
issue).

---

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0398r0.html

Reply via email to