http://d.puremagic.com/issues/show_bug.cgi?id=7493
--- Comment #5 from Don <[email protected]> 2012-03-21 14:14:57 PDT --- (In reply to comment #4) > DMD is inconsistent here. It is not clear what the behavior should be. > > void main(){ > string[] s1,s2; > s1=s1~[]; > s2~=[]; > writeln(s1," ",s2); // [""] [] > } > > I think most reasonable would be to check the array type for implicit > conversions first and to consider the element type for implicit conversions > only after the conversion to the array has failed. I don't think that's the same issue, and I don't like that approach for initialization of void[]. It would mean that void[][3] a = [ str, str, str]; void[][2] b = [ str, str, str]; means a[0] == str b[0] == [str, str, str] I think this particular issue is specific to void[], since it is a recursive type (an array literal of void[] elements is also of type void[]). The most intuitive approaches I would think are: * void[][ANYTHING] = [ WHATEVER ] is _always_ a whole-array assignment; OR it is _always_ an error. The current compiler behaviour, where it is always a block assignment, is less intuitive but I think defensible. But allowing it to be one or the other, depending on whether the implicit conversion succeeds, is horribly unpredictable. As far as I can tell, there is no mention at all of block assignment in the spec! Did I miss it? > This would make > appending/concatenating with an empty array literal a no-op for all array > types > and it would restore the behavior the OP expects. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
