Bug 11415 – Assign range to array

I would have expected the following to work: int[] d = [1,2,3,4,5,6,7]; d[] = d.filter!(x => x > 3)[]; Where the rhs could have been assigned to the lhs. Unfortunately this gives the following: Error: cannot implicitly convert expression (f.opSlice()) of type FilterResult!(__lambda2, int[]) to int[] For now, the only idiomatic solution I could find is this roundabout way: auto t = d.filter!(x => x > 3).copy(d); d = d[0 .. $ - t.length];

Seconded. If an operator implements opSlice it should behave as expected for a r-value per the Array assignment documentation. This can be converted to a similar foreach() loop that arrays are.

Filter produces a lazy range. In other words, it is not an int array. To store the result of filter in d[] you need to eagerly evaluate it. To do that you can use std.array.array on the result of filter. The code becomes: int[] d = [1,2,3,4,5,6,7]; d = d.filter!(x => x > 3).array(); If this answers your question, please close the bug. http://dlang.org/phobos/std_array.html#.array

(In reply to comment #2) > Filter produces a lazy range. In other words, it is not an int array. To store > the result of filter in d[] you need to eagerly evaluate it. To do that you can > use std.array.array on the result of filter. > The code becomes: > > int[] d = [1,2,3,4,5,6,7]; > d = d.filter!(x => x > 3).array(); > > If this answers your question, please close the bug. > > http://dlang.org/phobos/std_array.html#.array Yes. Do note though that this will allocate a new array, and not *copy* filter "into" the "d" array. Not that it's wrong, I just want to highlight it, as I don't think its quite what the op wanted. If you want to assign the *contents*, then std.algorithm.copy will do what you want: http://dlang.org/phobos/std_algorithm.html#copy int[] d = [1,2,3,4,5,6,7]; d.filter!(x => x > 3)().copy(d);

(In reply to comment #0) > I would have expected the following to work: > > int[] d = [1,2,3,4,5,6,7]; > d[] = d.filter!(x => x > 3)[]; I'm surprised filter has opSlice() at all: It's not a range primitive, and is useless. If anything, it leads to error (as you just tried to use it) > Error: cannot implicitly convert expression (f.opSlice()) of type > FilterResult!(__lambda2, int[]) to int[] opSlice should be removed from filter, or any other range. It only makes sense for containers (including static arrays), or plain dynamic arrays.

See also Issue 10176 for an array append of a lazy range.

@monarchdodra, that's true, however even this usage of copy is wrong as d should change length. Printing d after the copy produces: [4, 5, 6, 7, 5, 6, 7] where it is meant to be [4, 5, 6, 7] So you'll either have to go with what daniel350 had in his first post, or with the allocating array call.

(In reply to comment #6) > @monarchdodra, that's true, however even this usage of copy is wrong as d > should change length. > > Printing d after the copy produces: [4, 5, 6, 7, 5, 6, 7] > where it is meant to be [4, 5, 6, 7] > > So you'll either have to go with what daniel350 had in his first post, or with > the allocating array call. Huh. I didn't even notice OP had gotten it right in his original post. Serves me for not fully reading. I guess it really boils down to if you want a new array, or if you want to overwrite existing data. For example, copy can be used to write inside a slice taken from a stack allocated static array.

The point is that the syntax is listed in http://dlang.org/arrays.html. This syntax should be extended to forward ranges since that is how one would *EXPECT* it to work. Either that or the array vector copy syntax should be abandoned.

(In reply to comment #8) > The point is that the syntax is listed in http://dlang.org/arrays.html. This > syntax should be extended to forward ranges since that is how one would > *EXPECT* it to work. Either that or the array vector copy syntax should be > abandoned. The array vector copy is more than just convenient syntax: It's a request for a vectorized operation, which is built into naked arrays. If this syntax did work, you'd *EXPECT* a vector operation too, but you'd be getting a plain foreach copy, which would be just as wrong, but less explicitly so.

You mean what you get right now with that syntax for arrays? None of those array vector style operations turn into SIMD instructions. That's what we have std.simd; for.