On Thu, Mar 17, 2011 at 10:41 AM, Jason Merrill wrote:
> On 03/16/2011 11:44 PM, Gabriel Dos Reis wrote:
>>
>> I am not sure we need more infrastructure or more complexity
>> in the implementation. The (C++98) language already requires
>> us to initialize subobjects in their order of declaration.
On 03/16/2011 11:44 PM, Gabriel Dos Reis wrote:
I am not sure we need more infrastructure or more complexity
in the implementation. The (C++98) language already requires
us to initialize subobjects in their order of declaration. That is what
we do here. All we need is to check that a member, w
On Wed, Mar 16, 2011 at 10:02 PM, Jason Merrill wrote:
> On 03/16/2011 10:43 PM, Gabriel Dos Reis wrote:
>>
>> The real problem is that the data member of the object is not initialized.
>> Fully constructed subobjects in constexpr constructor are still
>> be potential constant expressions.
>> For
On 03/16/2011 10:43 PM, Gabriel Dos Reis wrote:
The real problem is that the data member of the object is not initialized.
Fully constructed subobjects in constexpr constructor are still
be potential constant expressions.
For example, we should not reject
struct S {
int i;
On Wed, Mar 16, 2011 at 9:32 PM, Jason Merrill wrote:
> In a normal constexpr function, we treat *this as a potential constant
> expression. But in a constexpr constructor it isn't, since we're still in
> the process of initializing the object.
Hi Jason,
I believe the patch is too strong, or am
