Bug 4287 – opOpAssign!("~=") for std.array.Appender

In std.array.Appender I'd like to use opOpAssign!("~=") instead of the put() member function. Is this possible? This is handy because in some situations I can almost replace a dynamic array with an Appender, keeping the same appends ~= unchanged in the code. std.array.Appender can even support two more operations (with complexity O(n ln n) or better) that I have found sometimes useful in my D1 code that uses a struct similar to Appender (but this is less important. Such operations can be allowed even if Appender gets implemented for example with a deque data structure): - length attribute - opIndex() An Appender is not an array, so it's better to not support opIndexAssign or opIndexOpAssign, etc. But peeking inside the Appender data structure with an opIndex() can be sometimes useful and avoids converting the Appender to a whole new array (that can be a costly operation if Appender changes its data structure implementation).

The put() method is not easy to remember (other collections use insert(), etc), so for me the ~= is simpler to remember. The needed code for Appender, tested a little: /// Adds or appends data to the managed array. void opOpAssign(string op:"~", T)(T data) { this.put(data); } It allows to write: import std.stdio, std.array; void main() { auto a = appender!(int[]); a ~= [1, 2]; a ~= 3; writeln(a.data); } ---------------------- To define an appender of integers I suggest a syntax like: auto a = appender!(int); Instead of: auto a = appender!(int[]); because the significant type here is of the items added to the appender. The fact that Appender uses an array to store such items is an implementation detail the user must be able to ignore (an Appender may be implemented with a dynamic array of fixed-sized arrays of items too, like some C++ deque data structures, to decrease large memory allocations, at the cost of a slower O(n) "data" method to convert the items in an array). ---------------------- An O(log n) opIndex() too is useful for Appender, it's also useful to avoid some usages of "data" method.

*** Issue 5791 has been marked as a duplicate of this issue. ***

See a discussion thread here, where I have suggested to give Appenhder both "put" method and a "~=" operator: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=33135 http://forum.dlang.org/thread/[email protected] Adam D. Ruppe: > Another annoyance is if you have a function that works on > regular arrays, you probably used ~=. > But you decide to switch to Appender to try for a speed boost. > Now you have to change all the usage too, since the > interfaces are incompatible! See other messages in the thread. Adam D. Ruppe, James Miller, Sönke Ludwig and Timon Gehr seem to agree to add the "~=" to Appender.

Question: Why was opOpAssign in that pull implemented with returning the 'this' reference? I saw this in TDPL too, but I don't see the benefit of having this compile: (foo ~= 1) ~= 1; Anyway as that pull was closed since it did too much I'm taking over this enhancement.

(In reply to comment #5) > Why was opOpAssign in that pull implemented with returning the 'this' > reference? I saw this in TDPL too, but I don't see the benefit of having this > compile: > > (foo ~= 1) ~= 1; Sometimes I like the assignment to return the value, to write: a = b = c; But I think the append doesn't need to return a value.

It seems the length attribute (and opIndex()) didn't get in this patch. I don't know if they are worth another ER.

(In reply to comment #8) > It seems the length attribute (and opIndex()) didn't get in this patch. I don't > know if they are worth another ER. I seemd to have skipped this part of the request. But you can open a new request for this.

(In reply to comment #9) > I seemd to have skipped this part of the request. But you can open a new > request for this. OK. The length attribute is useful, to know at what point of the appending you are... But is adding opIndex() a good idea? It makes an appender a bit more similar to an array. For some implementations Appender.opIndex() is O(ln x) instead of O(1). (And in the end what's the point of keeping both Appender and std.array.Array? Isn't a well implemented Array (with a .data attribute) enough?). Despite I think Appender.length is useful and I like it, at the moment I don't have a clear use case for it in my D2 code. So unless I or other people will need it, I think I will not open another ER for now. Thank you.