[Issue 7493] Initialization of void[][N]

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7493



--- Comment #5 from Don <clugdbug at yahoo.com.au> 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: -------