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.
