Code: ------------------------------------------ import std.array; E[] fastCopy(E)(E[] src) { auto app = appender!(const(E)[])(); foreach (i, e; src) app.put(e); return app.data; } E[] slowCopy(E)(E[] src) { E[] result; foreach (i, e; src) result ~= e; return result; } void main() { class C {} struct S { const(C) c; } S[] s = [ S(new C) ]; //auto t = fastCopy(s); // Does not compile auto t = slowCopy(s); } ------------------------------------------ If fastCopy is used in place of slowCopy, dmd git head gives: ------------------------------------------ /usr/src/d/phobos/std/array.d(2256): Error: cannot modify struct (cast(S*)(*this._data).arr)[len] S with immutable members test.d(6): Error: template instance std.array.Appender!(const(S)[]).Appender.put!(S) error instantiating test.d(22): instantiated from here: fastCopy!(S) test.d(7): Error: cannot implicitly convert expression (app.data()) of type const(S)[] to S[] test.d(22): Error: template instance test.fastCopy!(S) error instantiating ------------------------------------------ Is there any workaround for this? What I'm trying to accomplish is to copy an array of elements with const fields, but selectively skip elements based on some predicate (so straight .dup is out of the question). But using =~ is slow because of continual resizing/reallocation.
*** Issue 9667 has been marked as a duplicate of this issue. ***
The problem is that appender is making the double assuption that unqual implies assignability, and that copyiable implies assignability (empace ony requires copyability). Finally, it makes the wrong assumption that you can call opAssign on something that is not yet initialized (append makes raw allocations). Amongst a few other bugs mind you. There is a lot of broken in appender that I've tried to fix before, but it is very tricky because: 1) It is a ritical function that is used for strings, and needs to support CTFE. 2) Anything that fixes emplace must not slow it down. 3) It should be calling emplace instead of opAssign but emplace is currently broken for exactly the same reasons! I should maybe try to fix it in smaller incremental steps, but it is very hard to knowingly deliver code that you know is broken, and know how to fix.
(In reply to comment #2) > The problem is that appender is making the double assuption that unqual implies > assignability, and that copyiable implies assignability (empace ony requires > copyability). Finally, it makes the wrong assumption that you can call opAssign > on something that is not yet initialized (append makes raw allocations). > Amongst a few other bugs mind you. > > There is a lot of broken in appender that I've tried to fix before, but it is > very tricky because: > 1) It is a ritical function that is used for strings, and needs to support > CTFE. > 2) Anything that fixes emplace must not slow it down. > 3) It should be calling emplace instead of opAssign but emplace is currently > broken for exactly the same reasons! > > I should maybe try to fix it in smaller incremental steps, but it is very hard > to knowingly deliver code that you know is broken, and know how to fix. Possible solution for this: static if (__traits(compiles, { _data.arr.ptr[len] = cast(Unqual!T) item; })) { _data.arr.ptr[len] = cast(Unqual!T) item; } else { memcpy(&_data.arr.ptr[len], cast(Unqual!(T)*) &item, T.sizeof); }
*** Issue 10753 has been marked as a duplicate of this issue. ***
https://github.com/D-Programming-Language/phobos/pull/1529
This seems fixed to me. There is a little bug inside the "fastCopy" code, but there is no issue in Appender itsself.