From the feedback thread:
On Friday, 8 January 2021 at 00:57:37 UTC, Q. Schroll wrote:
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][]
I really don't like the `.staticArray` because it's non-esthetic.
I don't know if it's really argument, mainly because it's very
personal.
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.
Good point.
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]));
Correct. I'll rewrite this example.
There should be a type conversion:
```
int[2] bar() { return [1,2]; }
long[$] a6 = bar(); // implicit conversion
static assert(is(typeof(a6) == long[2]));
```
Now it makes more sense.
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.
:scratching my head:
B. The DIP says that int[2] and int[$] may end up the same
thing, but document different intent.
wtf. No ?
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.
The previous attempt was reverted because of control-flow
analysis that was needed.
There could be much better examples.
Yes.
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.
I don't think, it's an old feature. Even BCPL had it.
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.
If I implement it, would people more agree with the DIP ?
For me it's a nonsense (and a waste of time, if the DIP is not
accepted).
