On Tuesday, 14 August 2018 at 17:49:32 UTC, Mike Franklin wrote:
On Tuesday, 14 August 2018 at 17:22:42 UTC, Seb wrote:
FYI: staticArray will be part of 2.082, it already works with
dmd-nightly:
That just seems wrong. Isn't the fact that `staticArray` is
needed a bug in the compiler? I think the compiler could have
lowered to something like that automatically to avoid the
library workaround.
Mike
It's not a bug, it's all about how the type system is set up. The
type of an array literal expression like `[1, 2, 3]` is `int[]`
(a slice of an array of ints), so no matter if you do:
auto readonly(T)(const(T)[] x) { return x; }
auto arr1 = [1, 2, 3];
auto arr2 = [1, 2, 3].readonly;
const arr3 = [1, 2, 3];
enum arr4 = [1, 2, 3];
static immutable arr5 = [1, 2, 3];
scope arr6 = [1, 2, 3];
In all instances the type will be `int[]` modulo type qualifiers.
Static arrays are completely different types, that just happen to
accept
assignments from slices. Their two defining properties are:
1. Their length is fixed at compile-time, meaning that you can do:
import std.array, std.meta;
auto x = [1, 2, 3, 4, 5].staticArray;
enum length = x.length;
pragma (msg, length);
alias seq = AliasSeq!(0, 42, length);
static foreach (i; 0 .. length) { }
static foreach (i; seq) { }
2. Where slices are reference types, static arrays are value
types which means that each assignment will copy an entire array.
Basically they behave like a `struct { int _arr_0 = 0, _arr_1 =
1, _arr_2 = 2; }`.
https://run.dlang.io/is/iD9ydu
