Why isn't array literal size mismatch caught at compile time?

Question

I have the following code:

import std.stdio;

int main(string[] args)
{
   int[3] my_array = [1, 2];
   return 0;
}

This compiles fine, and then aborts when executed, giving this error:

arrays_init
object.Exception@src/rt/arraycat.d(31): lengths don't match for array copy
----------------
arrays_init(_Dmain+0x64) [0x416bbc]
arrays_init(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x1c) [0x418c5c]
arrays_init(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate())+0x2a) [0x4185d6]
arrays_init(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x3b) [0x418ca3]
arrays_init(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate())+0x2a) [0x4185d6]
arrays_init(main+0xd1) [0x418561]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f60bc41d30d]

This runs fine if the array literal has 3 items, so apparently the array literal has to match the size of the static array. But shouldn't this give a compile error since the size of both can be calculated at compile time?

Answer 1

Array literals are of type T[], i.e. they are dynamic arrays that are unaware of their size at compile time.

Your code compiles for the same reason this compiles:

void foo(int[] xs)
{
    int[3] ys = xs;
    ...
}

The compiler simply doesn't know how big xs is.

In your case, the compiler could know at compile time because all the information is there, but it would be going above and beyond what the compiler is obligated to do. Interpreting the code strictly, there is no type mismatch, so it compiles.

Another side effect of array literals being dynamic arrays is that the code you have will actually allocate memory. It allocates the dynamic array on the heap, copies into the static array, and then you have to wait for a garbage collection cycle before the memory is reclaimed. This can be a cause of bad performance if you initialise arrays like that in a tight loop.

Again, the compiler could avoid the allocation, but DMD at least does not in the current version (2.060).