[Issue 11138] "real" appender missing

[d-bugmail at puremagic.com]

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



--- Comment #3 from monarchdodra at gmail.com 2013-09-29 09:41:29 PDT ---
(In reply to comment #2)
> (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.

Right. Sorry.

Wait. How do you append something that can't be copied? Is this even relevant?

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

You have a point.

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

Not really, the appender API is rich enough for appender to "know" if anybody
else has yet accessed the array, either through arr, or via construction. If no
one else has a handle on the array, and appender is about to relocate, then it
can pretty much do anything it wants.

Maybe the word "owns" is inadequate. The bool would be called
"arrayHasExternalView".

> > > 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 think appender was mostly to offset how ridiculously slow ~= is. I'm not sure
it wasn't design with *absolute* performance in mind.

BTW, you might want to know about:
http://d.puremagic.com/issues/show_bug.cgi?id=10864

Off topic: I'd like to try to make a push for some templatization in druntime.
I thought you might be interested in the project. I'll keep you posted.

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

You are creating a copy. Appender can be used to append to an existing array,
whith lots of capacity, without relocating it. This can be very useful for say,
processing lines in IO, where you are re-using the same buffer for each line.

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

Well very rare remains to be proven. Still, I don't think it's that big of a
problem if a "real" appender simply duplicated before allocating: To each their
own behavior. You can't get "super speed" if you aren't willing to give
appended total ownership of the passed data.

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