www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4287] New: opOpAssign!("~=") for std.array.Appender

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287

           Summary: opOpAssign!("~=") for std.array.Appender
           Product: D
           Version: future
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 06 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287


Rob Jacques <sandford jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alvaro.segura gmail.com



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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287




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/jimj6f$1vq$1 digitalmars.com

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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 12 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287


Rob Jacques <sandford jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandford jhu.edu



https://github.com/D-Programming-Language/phobos/pull/502

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 19 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com
           Platform|Other                       |All
         AssignedTo|nobody puremagic.com        |andrej.mitrovich gmail.com
         OS/Version|Windows                     |All



15:20:42 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
            Version|future                      |D2



15:41:57 PST ---
https://github.com/D-Programming-Language/phobos/pull/1108

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287







 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 03 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287


Alex Rĝnne Petersen <alex lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |alex lycus.org
         Resolution|                            |FIXED


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287




16:47:07 PST ---


 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4287







 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 07 2013