[cfe-commits] r159733 - in /cfe/trunk: lib/Sema/SemaInit.cpp test/CodeGenCXX/const-init-cxx11.cpp test/CodeGenCXX/constructor-init.cpp test/SemaCXX/constant-expression-cxx11.cpp test/SemaCXX/cxx0x-initializer-constructor.cpp

[Johannes Schaub]

Am 08.07.2012 20:30, schrieb Richard Smith:
> On Sun, Jul 8, 2012 at 6:41 AM, Johannes Schaub
> <schaub.johannes at googlemail.com
> <mailto:schaub.johannes at googlemail.com>> wrote:
>
>
>
>     Am 05.07.2012 10:39, schrieb Richard Smith:
>
>         Author: rsmith
>         Date: Thu Jul  5 03:39:21 2012
>         New Revision: 159733
>
>         URL: http://llvm.org/viewvc/llvm-__project?rev=159733&view=rev
>         <http://llvm.org/viewvc/llvm-project?rev=159733&view=rev>
>         Log:
>         PR13273: When performing list-initialization with an empty
>         initializer list,
>         actually perform value initialization rather than trying to fake
>         it with a call
>         to the default constructor. Fixes various bugs related to the
>         previously-missing
>         zero-initialization in this case.
>
>         I've also moved this and the other list initialization 'special
>         case' from
>         TryConstructorInitialization into TryListInitialization where
>         they belong.
>
>     ...
>
>         +namespace explicit_default {
>         +  struct A {
>         +    explicit A(); // expected-note{{here}}
>         +  };
>         +  A a {}; // ok
>         +  // This is copy-list-initialization, and we choose an
>         explicit constructor
>         +  // (even though we do so via value-initialization), so the
>         initialization is
>         +  // ill-formed.
>         +  A b = {}; // expected-error{{chosen constructor is explicit}}
>         +}
>         +
>
>
>     Richard, I'm pretty sure that this is valid code. A
>     value-initialization doesn't respect "explicit". Are you assuming a
>     C++ Standard defect here?
>
>
> Here's my reading of the standard:
>
> By 8.5.4/1, this is copy-list-initialization. By 8.5.4/3, the object is
> value-initialized. By 8.5/7, "the default constructor for T is called".
> That's all normal.
>
> Now, the question is, does 13.3.1.7 apply when choosing the default
> constructor to call, in the case where T has a default constructor and
> so list-initialization delegates to value-initialization? If so, "In
> copy-list-
> initialization, if an explicit constructor is chosen, the initialization
> is ill-formed." And I think 13.3.1.7 is actually pretty clearly intended
> to apply to this case, because it says "If the initializer list has no
> elements and T has a default constructor, the first phase is omitted." So
> I think the standard is clear here that this should be ill-formed.
>

The special casing of default constructors at 13.3.1.7 was not intended 
to make calls of explicit default constructors during value 
initialization ill-formed.

It was intended to harmonize clause 13 with clause 8, because clause 13 
directly invokes 13.3.1.7 from 13.3.3.1.5 instead of special casing 
default constructors at that place.

They fixed that by modifying 13.3.1.7 instead of introducing a new 
bullet in 13.3.3.1.5. See 
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1229

Regarding 8.5.4/3, it doesn't necessarily state that overload resolution 
is done. It simply says the "default constructor of T is called".

The way that DR1229 was fixed however makes this thing way less clear 
than I initially felt it is, so I will partially agree with you that 
clang's trunk position is not all that bad, but I still feel like this 
should be talked with core (GCC does not implement it like this, for one).