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?
