ae.utils.appender: check for Allocator.deallocate

[pbackus]

Needed to unblock dlang/phobos#8554

[CyberShadow]

Maybe I don't understand something, but would it not be useful for data structure implementations to enforce the availability of allocator primitives? E.g. some data structures may be grow-only, and therefore truly not need the deallocate method, and some may allocate/deallocate memory and therefore actually need for the allocator to support deallocation?

As it is, this change will make passing an allocator that truly can't deallocate silently leak memory.

I will follow up in the Phobos PR as well.

[pbackus]

If a data structure absolutely requires deterministic deallocation, then yes, of course it can require that its allocator implement deallocate (and it should probably also check the return value, to make sure it's working).

In general, though, if a user goes out of their way to create an allocator that leaks memory, and instantiates a container with that allocator, it probably should not be the container's job to second-guess the user's intentions. Sometimes programmers leak memory on purpose (see: DMD).

[CyberShadow]

In general, though, if a user goes out of their way to create an allocator that leaks memory, and instantiates a container with that allocator, it probably should not be the container's job to second-guess the user's intentions.

I think a more correct and elegant approach to address that would be a shim layer as described here: dlang/phobos#8554 (comment)

[CyberShadow]

BTW on the topic of shim layers, it should be easier to write them:
https://github.com/CyberShadow/btdu/blob/c5dc72d82ee98f0efdd37ef3830fead00bf44a63/source/btdu/alloc.d#L60-L61