is this a betterC bug ?

[Petar]

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