Is there something special required to use Appender.clear

[Steven Schveighoffer]

On 1/25/19 3:20 AM, FeepingCreature wrote:
> On Thursday, 24 January 2019 at 17:49:34 UTC, Ali Çehreli wrote:
>> On 01/24/2019 04:35 AM, FeepingCreature wrote:
>> > On Tuesday, 27 March 2018 at 12:31:05 UTC, Simen Kjærås wrote:
>> >> On Tuesday, 27 March 2018 at 12:17:58 UTC, Ellie Harper
>> wrote:
>> >>> Sorry if this is a stupid question, but is there something
>> special
>> >>> required to call Appender.clear?  When I attempt even just
>> a simple
>> >>> use I am getting compile errors relating to `template
>> object.clear`.
>> >>
>> >> From the documentation for Appender:
>> >>
>> >>> Note
>> >>> clear is disabled for immutable or const element types, due
>> to the
>> >>> possibility that Appender might overwrite immutable data.
>> >>
>> >> Since string is immutable(char)[], clear() is simply not
>> available for
>> >> appender!string.
>> >>
>> >> --
>> >>   Simen
>> >
>> > Isn't this wrong, though? Appender controls the memory it
>> references. It
>> > could just choose to allocate non-immutable memory
>> internally. As long
>> > as any const data put into the appender is *returned* as
>> const, there is
>> > no chance of immutable memory being overwritten.
>>
>> I think Appender is trying to protect previous data from Appender's 
>> later use. If it handed out immutable data, the user is expecting it 
>> to not change. So, Appender cannot clear it for later use.
>>
>> Ali
> 
> 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.

> 
>> Appender is sometimes given a starting array. clear isn't callable in 
>> that case, and we don't distinguish the difference in the type or at 
>> runtime.
> 
> 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.

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?

-Steve