Feedback Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1

[Q. Schroll]

The DIP massively fails to provide a good rationale why 
std.array.staticArray is insufficient. It looks unpleasant, but 
does the job in practically all cases demonstrated in the 
examples a1 through a6.

Example a1 currently doesn't work exactly because staticArray 
returns immutable(char)[6], not char[6]. One needs a 
char-specific function that is trivial to write:

     C[n] staticCharArray(C, size_t n)(auto ref const(C)[n] 
charArray)
     {
         return charArray;
     }

Then, example a1 can be written as:
     auto a1 = "cerise".staticCharArray;
     static assert(is(typeof(a1) == char[6]));

Example a2 needs enum, but as long as someone knows what they're 
doing, enum int[] is fine:
     enum int[] d = [1, 2, 3]; // enum instead of const
     auto a2 = d.staticArray;
     static assert(is(typeof(a2) == int[3]));

Example a3 is straightforward the primary use case for 
staticArray:
     auto a3 = [1,2,3].staticArray;

Example a4 is, too.
     auto a4 = [[1,2].staticArray, [3, 4]];
     pragma(msg, typeof(a4)); // int[2][]

Example a5 is the first one that's actually painful to work 
around:
     enum a5DefaultValue = [1,2].staticArray;
     void foo(typeof(a5DefaultValue) a5 = a5DefaultValue)
     {
         static assert(is(typeof(a5) == int[2]));
     }
I think this is rather an argument for allowing type deducted 
defaulted function parameters generally, not only static arrays.

Example a6 is the prime use-case for auto type deduction:
     int[2] bar() { return [1,2]; }
     auto a6 = bar();
     static assert(is(typeof(a6) == int[2]));

This feature would have a reasonable chance of being accepted 
some years ago. Since this is the feedback thread, here's my 
constructive feedback:

A. You maybe need better examples. Ease of reading and writing 
code can be an argument. You may want to state it somewhere. 
Unfortunately, this isn't a very good one. If you can come up 
with examples where workarounds are at least slightly more 
unpleasant than the one for Example a5 (that don't look too 
artificial), it might work out.
B. The DIP says that int[2] and int[$] may end up the same thing, 
but document different intent. IMO, this is the best argument 
this DIP has. An immediate case where this is relevant is as a 
function return type. As an example, opSlice (as the lowering of 
the double-dots in xs[0 .. 1]) returns size_t[2]. It won't ever 
return another number of size_t, so size_t[$] would be wrong 
conceptually. Other functions returning static arrays might 
return T[4], but the 4 isn't particular to the use case. If it 
might change, this can be documented using T[$] so that uses of 
the function don't rely on the 4 too much.
This is merely an example I came up with thinking for a minute. 
There could be much better examples.
C. The DIP really must address the fact that what is gained is 
very minor. Therefore, the difficulty of the implementation and 
its maintenance in the compiler code plays a huge role. If you 
can provide an implementation that most people would agree isn't 
that big of a deal having in the compiler, that would be really 
valuable.