Is there something special required to use Appender.clear
feepingcreature at gmail.com
Mon Jan 28 12:39:56 UTC 2019
On Friday, 25 January 2019 at 14:33:16 UTC, Steven Schveighoffer
> On 1/25/19 3:20 AM, FeepingCreature wrote:
>> On Thursday, 24 January 2019 at 17:49:34 UTC, Ali Çehreli
>> Aren't the semantics of .clear that it's invalid to access
>> references to .data after calling .clear, period? And if not,
>> then shouldn't they be? Consider if Appender managed its own
>> memory and held on to previously-allocated arrays while you
>> were appending, only to free them on .clear. That seems like
>> something Appender should be allowed to do. If you don't want
>> it, just reinitialize Appender instead of calling .clear.
> You are advised not to. But it's not unsafe, as the memory is
> still there.
That's stupid. Why would you advise me not to, if there's no
problem with it? Either it should be accepted or it should be
forbidden, just like warnings.
>> Any reason that the semantics of .clear should be different
>> for a starting array? Anyway if so, I'd prefer to just make
>> that a runtime error.
> Yes, because Appender doesn't know where that memory comes
> from. A string could be, for instance, passed to another thread
> and being used, you wouldn't want to overwrite it.
In which case, you can't reuse the Appender and should not call
`clear`! It seems like we're gimping functionality of a very
basic tool for memory efficiency for the sake of not confusing
users. This rarely pays off.
> Generally speaking, overwriting immutable data is UB in D
> Making it a runtime error would be possible, but there has to
> be a good reason to make it that way.
>> I'm mostly fishing around if anyone has an objection to a PR
>> to change this.
> Without good reasons to change, I don't see why it would be
> Maybe you can describe your use case?
My use case is simply the standard usecase of Appender: I want to
build up an array in a way that reduces GC churn. Maybe it's an
array of structs that contain const members that I'll serialize
to JSON and send on a socket. In that case, I know for a fact
that no references will hang around past the serialization.
That's what clear _is for._ I don't see why this would be
different with const or immutable data; if you hold references
past .clear being called you're in trouble *anyways.*
I consider initializing Appender with an array referencing
immutable data a borderline error anyways. The entire point of
Appender is that it caches capacity data of GC managed memory,
which is never immutable. On the first append to an
immutable-memory array, it has to reallocate *anyways*. There is
no benefit to initializing an Appender with immutable memory over
just appending it first thing, unless you never plan to append to
More information about the Digitalmars-d-learn