Is there something special required to use Appender.clear

[FeepingCreature]

On Friday, 25 January 2019 at 14:33:16 UTC, Steven Schveighoffer 
wrote:
> 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.