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.

Reply via email to