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