<div dir="ltr">2013/6/4 Don <span dir="ltr"><<a href="mailto:turnyourkidsintocash@nospam.com" target="_blank">turnyourkidsintocash@nospam.com</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br></div>
There is still one problem, bug 10198. This currently compiles, and does something stupid:<br>
---<div class="im"><br>
struct U {<br>
   int [3][3] y;<br>
}<br>
<br></div>
U u = U(4);<br>
---<br>
What do you think should happen here?<br>
</blockquote></div><br></div><div class="gmail_extra">Oh! I did not know it is currently accepted.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think accepting multi-dimensional block initializing on StructLiteralExp arguments is very bug-prone behavior.</div>
<div class="gmail_extra">Different from variable declaration in statement scope, there is no target type we can look for. So inferring the cost of static array construction is difficult.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">struct U { int[3][3][3][3] w; }</div><div class="gmail_extra">U u = U(1);    // looks trivial, but actually costly operation.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
int[3][3][3][3] w = 1;   // initializing cost is very obvious</div><div class="gmail_extra"><br></div><div class="gmail_extra">At most it would be better that it is restricted up to one-dimensional block initializing, same as StructInitializer.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>Kenji Hara<br></div></div>