C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Jason Merrill]

On 12/13/2016 03:25 PM, Martin Sebor wrote:
> On 12/13/2016 12:06 PM, Jason Merrill wrote:
>> On 12/09/2016 07:46 PM, Martin Sebor wrote:
>>> On 12/09/2016 02:49 PM, Jason Merrill wrote:
>>>> On Fri, Dec 9, 2016 at 11:33 AM, Martin Sebor <msebor@gmail.com> wrote:
>>>>> For flexible array members, because they're not in C++, we get to
>>>>> make up the rules that make the most sense to us.  IMO, they should
>>>>> fit in well with the rest of the language.
>>>>
>>>> I disagree; we should support C code, but flexible arrays don't really
>>>> fit with the C++ object model, so I don't think trying to do anything
>>>> clever with them in constructors is worthwhile.
>>>
>>> With the suggested approach the array becomes just an ordinary member.
>>> It's not a flexible array member anymore because its bound is deduced
>>> from the initializer (it just looks like one).  The NSDMI char a[] =
>>> "foo" syntax is just a shorthand for char a[4] = "foo".
>>
>> That would mean that the size of the class varies with its initializer,
>> which again gets into not fitting with the C++ object model.
>
> Okay, I accept the challenge of finding a case where the size
> of a class depends on an initializer expression :)
>
> Here's one:
>
>   constexpr long f (int) { return 1; }
>   constexpr long f (long) { return LONG_MAX; };
>
>   struct A {   // sizeof (A) == 4
>     enum E { i = f (0) } e;
>   };
>
>   struct B {   // sizeof (B) == 8
>     enum E { i = f (0L) } e;
>   };
>
> It's not exactly the same but I think it's close enough to argue
> that deducing the array size from its initializer wouldn't go
> against the established model.

I don't see the similarity; A and B both have constant size.

Jason