Is there something special required to use Appender.clear

FeepingCreature feepingcreature at
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 
>> wrote:
>> 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 
> anyway.
> 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 
> accepted.
> 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 
it ever.

More information about the Digitalmars-d-learn mailing list