Consider this: void foo(float[4] x) { return x[0]+x[1]*x[2]-x[3]; } void main() { float[] xs = read_floats_from_file(); foreach (i; 0 .. xs.length-4) { foo(xs[ i .. i+4]); } } or simpler thing to calculate in compile time: void main() { float[] xs = read_floats_from_file(); foo(xs[ 0 .. 4]); } In both cases compiler will say: cannot implicitly convert expression (_adDupT((& _D11TypeInfo_Af6__initZ),qs[0u..4u])) of type float[] to float[4u] or something similar. It is hard to see why this is really needed. How about allowing (and performing) implicit cast to static array if compiler knows (or can easly infere) size of the slice and it aggree with target type? Of course there will be situations where we have no knowledge about it: void main() { float[] xs = read_floats_from_file(); uint a = rand() % xs.length; foo(xs[ 0 .. a ]); } But allowing implicit cast also can detect other errors: foreach (i; 0 .. xs.length-4) { foo(xs[ i .. i+3]); } Compiler in such situation will complain not because we are using float[] to float[4] conversion, but because we are trying to call float[4] function using float[3] slice.
So essentially problem is that slices are just dynamic arrays. So bringing back the topic of making slices different/distinctive types.
It is even worse that i was innitially thinking: explicit casting doesn't work: series2.d(113): Error: e2ir: cannot cast qs[0u..1u] of type float[] to type float[1u]
Partial implementation: https://github.com/D-Programming-Language/dmd/pull/1705 (In reply to comment #0) > float[] xs = read_floats_from_file(); > foreach (i; 0 .. xs.length-4) { > foo(xs[i .. i+4]); > } In this case, detecting length == 4 in compile time is difficult with complicated cases. Consider: foo(xs[(i*4+10)/2 .. (i*8>>1)/2+9]); // lwr = (i*4 + 10)/2 = i*4/2 + 10/2 = (i*2+5) // upr = (i*8>>1)/2 + 5 = (i*4/2) + 5 = i*2 + 9 = (i*2+5) + 4 So this is not supported in my pull request.
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/82b79c071c9ca13785e16c9faea901fa2c45531e partial fix Issue 3652 - Allow explicit and implicit casting of dynamic array slices of known size to static array If and only if both side of slice boundaries can be constant-folded, the conversion will succeed. Limitation: - Does not run CTFE. - There is no deformation of formula. https://github.com/D-Programming-Language/dmd/commit/e74670edbf1e013da748342a83909e2bce65d993 Merge pull request #1705 from 9rnsr/ct_slice partial fix Issue 3652 - Allow explicit and implicit casting of dynamic array slices of known size to static array
(In reply to comment #3) > So this is not supported in my pull request. Your pull request is not perfect, but it's a significant improvement. Maybe related: Issue 8277 and Issue 9165
*** Issue 8843 has been marked as a duplicate of this issue. ***
See also: issue 13700
Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/243a97c3ebde92cd3c3f99963e39591fc307fff3 Issue 3652 - Allow explicit and implicit casting of dynamic array slices of known size to static array https://github.com/D-Programming-Language/dlang.org/commit/900cd04b373192feea7d682150eabe10e34b793f Merge pull request #725 from 9rnsr/fix3652 Issue 3652 - Allow explicit and implicit casting of dynamic array slices of known size to static array
It does appear way better indeed. https://godbolt.org/z/taxeAR One way to emulate, the foo(xs[i .. i+4]), is by doing foo(xs[i .. i+4][0 .. 4]). It is hard to support arbitrary expression. Not only it would be very hard to write specification to indicate what kind of expressions are supported by compiler. in general function equality is equivalent to halting problem, so only some poorly defined subset (by algorithm) can be supported. compiler is not full symbolic algebra system, so it is probably not worth implementing or specifying. Thanks for the patches, Kenji.