Array Appenders

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Apr 6 20:43:42 PDT 2009


dsimcha wrote:
> Ever since D emerged from the primordial soup back in the Paleozoic Era,
> there's been discussion around here about array appending and the need/want
> for a capacity field.  To solve this problem, Andrei's pre-release Phobos
> includes an array appender struct (see
> http://www.erdani.dreamhosters.com/d/web/phobos/std_array.html).  While this
> gets the job done, IMHO it feels kind of hackish and undermining of builtin
> arrays, especially now that D supports alias this.
> 
> When alias this came out (yes, this was just last week but it feels like
> forever ago with the pace of evolution lately), I started playing around with
> the idea that an ArrayAppender!(T) should consist of an extremely thin wrapper
> around a T[].  It should implicitly convert to T[] and be usable exactly like
> a T[], except that it should have a capacity field and its ~= operator should
> be overridden to use the capacity field for fast appends.  IMHO this is a much
> more elegant solution than having an ArrayAppender that is a completely
> different animal than builtin arrays and doesn't allow access to the builtin
> array's operators without an explicit conversion.
> 
> Right now, my prototype of the implicitly-converting ArrayAppender doesn't
> work well due to bugs 2777, 2778, and 2781, but if there's sufficient
> interest, I'd be willing to release the prototype anyhow for comment after
> it's cleaned up a little.  What do others think?  Should arrays w/ capacity
> fields blend in with and implicitly convert to builtin arrays, or should there
> be a high wall distinguishing the two?

ArrayAppender is different from an array because it's supposed to 
disconnected from the array notion. It should only be an output range, 
and as such supports the put() method. Other output streams will 
mushroom for files, lists, sockets... so ArrayAppender is uniform with 
those. It's not supposed to be uniform with arrays.

Andrei



More information about the Digitalmars-d mailing list