Regarding std.array.Appender

James Miller james at aatch.net
Wed Feb 29 20:28:18 PST 2012


On 1 March 2012 15:49, Adam D. Ruppe <destructionator at gmail.com> wrote:
> On Thursday, 1 March 2012 at 02:44:35 UTC, Jonathan M Davis wrote:
>>
>> True, but it can't do all of the other operations that array can do
>> either.
>
>
> Yeah, but the one operation it replaces, ~=, can be done
> on an array.
>
> If you're trying to convert array code to Appender for
> speed, most likely you're going to be replacing a
> bunch of ~= calls.
>
> It's ok if the other op don't compile, but this one
> really should. Appender, regardless of the internal
> representation vs array is a speed optimization;
> an implementation detail.
>
>
>> It's an output range, not an array.
>
>
> It's also an Appender, though. I think it is a little
> silly to have an Appender to which you can't /append/.
>
> (put is great too, don't get me wrong, but so is ~=).

I can see both sides, but I'm on Adam's side here. While all the other
opOpAssign functions are defined in terms of their opBinary equivalent
(e.g, += is 'add and assign'), ~= is essentially an operator in its
own right, specifically an append (as opposed to '~' which is
concatenate). Having both ~= and .put() would be fine, and would make
switching from arrays to Appenders much easier.

I understand that Appenders aren't arrays, and should not be used as
such, but you /can/ use an array as an Appender. At some point, you
have to concede design purity to convenience, otherwise you have a
language that is actively hostile to changing designs. *In best
"nagging wife" voice* "You should have used an Appender from the
start. Now you have to go change all that code. Its your own fault
really."...

--
James Miller


More information about the Digitalmars-d-learn mailing list