[Issue 11138] "real" appender missing

[d-bugmail at puremagic.com]

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



--- Comment #2 from Denis Shelomovskij <verylonglogin.reg at gmail.com> 2013-09-29 19:12:23 MSD ---
(In reply to comment #1)
> (In reply to comment #0)
> > 3. Needless restriction on element type.
> >     ...
> 
> 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).

Mutability have nothing to do with copyability. Struct with disabled postblits
are meant here. And current appender design can't accept them.

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

So, you are talking that GC bug must force us to do bad design? I will accept
it only for an iron-WONTFIXed one.

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

Such flag will not work as Appender API allows safe access to the array so the
array can never be owned.

> > Obviously, "real" appender is uncopyable
> 
> Appender having ref semantics, there would be absolutely no problem "copying"
> it (read: pass by value).

Yes. And such ref semantic is not generally needed and just results in needless
GC allocation in stuff aimed for performance-critical tasks.

> 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 :/

It of course can't initialize from existing array if element isn't copyable.
Otherwise it will create its own copy of array. Where is the problem? Also we
talk here about very rare usage of the appender which I'd rather ignore just
like the case when its content is needed in the middle of appending as
non-general.

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

Exactly what I expect for each my proposal. :) So as always I will just create
one for my own use.

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