What's the point of static arrays ?

[Stanislav Blinov]

On Friday, 10 July 2020 at 10:13:23 UTC, wjoe wrote:
> So many awesome answers, thank you very much everyone!
>
> Less overhead,
> Using/needing it to interface with something else, and
> Efficiency are very good points.
>
> However stack memory needs to be allocated at program start. I 
> don't see a huge benefit in allocation speed vs. heap 
> pre-allocation, or is there?

Stack is allocated by the OS for the process when it's started. 
Reserving space for stack variables, including arrays, is 
effectively free, since the compiler assigns offsets statically 
at compile time.

> I mean 1 allocation vs 2 isn't going to noticeably improve 
> overall performance.

A GC allocation is way more complex than a mere bump-the-pointer. 
If your program is trivial enough you may actually find that one 
extra GC allocation is significant in its runtime. Of course, if 
you only ever allocate once and your program runs for ages, you 
won't really notice that allocation.

>>     a[]
> What happens here exactly ?

This:

int[10] a;
int[] slice = a[];
assert(slice.ptr == &a[0]);
assert(slice.length == 10);
assert(a.sizeof == 10 * int.sizeof);    // 40
assert(slice.sizeof == (int[]).sizeof); // 16 on 64 bit

> I read the chapters in Ali's book (thank you very much for such 
> a great book, Ali) on arrays and slicing prior to asking this 
> question and I came to the following conclusion:
>
> Because a static array is pre-allocated on the stack,
> doesn't have a pointer/length pair,
> is addressed via the stack pointer, and
> due to the fact that a slice is a pointer/length pair
>   and because a slice is technically the meta data of a dynamic 
> array, a view into (part) of a dynamic array,

No. A slice is just a pointer/length pair - a contiguous view 
into *some* memory, regardless of where that memory came from:

void takeASlice(scope void[] data) // can take any slice since 
any slice converts to void[]
{
     import std.stdio;
     writefln("%x %d", data.ptr, data.length);
}

int[10] a;
takeASlice(a); // a[]
takeASlice(a[1 .. $-1]); // a[1 .. 9]

struct S
{
     float x, y, z;
     float dx, dy, dz;
}

S s;
takeASlice((&s)[0 .. 1]); // Slicing a pointer, not @safe but can 
be done.
takeASlice(new int[10]); // Array, GC allocation
takeASlice([1, 2, 3, 4]); // Array literal, may or may not be 
GC-allocated

`takeASlice` has no knowledge of where the memory came from.

Dynamic arrays only ever come into the picture if you try to 
manipulate the slice itself: resize it, append to it, etc.

> that it's not possible to slice a static array because the 
> slice would technically be akin to a dynamic array and hence be 
> incompatible.

Incompatible to what?

int[10] a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
a[0 .. 2] = a[2 .. 4];
assert(a[0] == 3);
assert(a[1] == 4);
int[10] b = void;
b[] = a[];
assert(b == [3, 4, 3, 4, 5, 6, 7, 8, 9, 10]);

> struct SuperSpecializedArray(T, size_t S) if (S > 0)
> {
>    T[S] elements;
>
>    struct SuperSpecializedArrayRange
>    {
>       typeof(elements) e;
>
>       this(SuperSpecializedArray a)
>       {
>          e = a.elements; // copies
>       }
>
>       // ...
>    }
> }
>
> Upon creation of a SuperSpecializedArrayRange, the array is 
> copied, but more importantly, data which may not ever be needed 
> is copied and that's supposed to be a big selling point for 
> ranges - only ever touching the data when it's requested - am I 
> wrong ?

Ranges need not be lazy. They can be, and most of them should be 
indeed, but they need not be. And, as you yourself point out, in 
your case `e` can just be a slice, and your range becomes lazy.