[Issue 11138] "real" appender missing

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=11138


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra at gmail.com


--- Comment #1 from monarchdodra at gmail.com 2013-09-29 04:03:25 PDT ---
(In reply to comment #0)
> 3. Needless restriction on element type.
>     One may want to create and array of uncopyable type which non-"real"
> appender can't do by definition.

Appender supports immutable construction (mostly bug free, AFAIK). I don't
think a "real" appender would do any better than appender could anyways, so
this is a non-argument (IMO).

> 2. Performance.
>     It will cause calls of postblits and then destructors on collection of copy
> array.

Technically, the destructors don't need to be called, since the GC will leak
them anyways :/ See below about "postblits"

> Lets call "real" an appender which will create the one and only array, i.e. it
> will not randomly create a copy of array on appending. Such copy is bad as:
> 1. Almost no use.
>     In 99% appender is used as "real" appender and the copy is not needed.

I've thought about this before. The *only* case this would really change
anything, is on structs that have an elaborate CC. Arguably, these things have
no business being in a GC managed array, since it never finalizes its elements
(and arguably, if you have a CC, you have a destructor). If we ever get a
finalizing GC, then things will be different.

One "workaround" I've though about is that when the type has a CC, Appender
could carry an extra "ownsArray" boolean. If appender must relocate its array,
and "owns" the array, then postblit is not necessary. In the future, if the GC
is finalizing, it may also have to re-initialize to T.init, if there is an
elaborate destructor.

> Obviously, "real" appender is uncopyable

Appender having ref semantics, there would be absolutely no problem "copying"
it (read: pass by value).

> and don't give safe access to its
> array until it finished.

I can see the motivation behind this "real" appender. Another (dis)advantage it
has is that it wouldn't be initialize-able from an existing array. This means
it would have 100% ownership of its internals, but on the other hand, it also
means, it also means it can't extend an exiting array :/

So, "at the end of the day", I'm not really sure a "real" appender would pull
its weight compared to the standard appender (IMO).

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