We need to define the semantics of block initialization of arrays
Don
turnyourkidsintocash at nospam.com
Tue Jun 4 04:46:18 PDT 2013
On Tuesday, 4 June 2013 at 02:33:54 UTC, Kenji Hara wrote:
>> Personally I'd like to just use block-init everywhere. I
>> personally find
>> first-element-init rather unexpected, but maybe that's just
>> me. I don't
>> know when it would be useful. But regardless, we need to get
>> this sorted
>> out.
>> It's a blocker for my CTFE work.
>>
>
> First-element-init is definitely a bug. I can argue that nobody
> wants the
> strange behavior.
Good, it seems that everyone agrees. It's therefore a bug in
todt.c, StructInitializer::todt()
>> void main()
>> {
>> int [3][4] w = 7;
>> assert( w[2][2] == 7); // Passes, it was block-initialized
>>
>
> Currently block-initialization for multi-dimensional static
> array is just
> only allowed for variable declaration in statement scope.
> I'm planning to fix bug 3849 and 7019, but changing this
> behavior might
> affect them. As my hope, I'd like to keep this as-is so I've
> not finished
> thinking about it well.
Yeah, there's difficulties with things like:
int [3][4] = [7, 7, 7];
which could be a block initialization -- is this allowed or not?
Though I think we have already dealt with such issues for block
assignment.
> S s = { 8 }; // OK, struct static initializer.
> first-element-init
>>
>
> This is definitely a bug. Instead, block-init should occur.
Good.
>
>
>> S r = S( 8 ); // OK, struct literal, block-init.
>> T t; // Default initialized, block-init
>>
>
> OK.
>
>
>> assert( s.x[2] == 8); // Fails; it was
>> first-element-initialized
>>
>
> Also, definitely a bug.
>
>
>> assert( r.x[2] == 8); // Passes; all elements are 8.
>> Block-init.
>> assert( t.x[2] == 8); // Passes; all elements are 8.
>> Block-init.
>>
>
> OK.
>
>
>> U u = { 9 }; // Does not compile
>> // Error: cannot implicitly convert expression (9) of type
>> int to
>> int[3LU][3LU]
>>
>
> For reasons I've already mentioned in `int [3][4] w = 7;`, I'd
> like to keep
> this current behavior.
There is still one problem, bug 10198. This currently compiles,
and does something stupid:
---
struct U {
int [3][3] y;
}
U u = U(4);
---
What do you think should happen here?
More information about the Digitalmars-d
mailing list