Vladimir Panteleev

> 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...

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

There are some stand-alone tests in the `test` directory, maybe that would be a good place?

> * Making GCAllocator.deallocate a no-op method that always returns > false. The documentation in std.experimental.allocator.building_blocks > specifically says not to do that. What about making `GCAllocator.deallocate` a no-op method...

I subjectively disagree with this paragraph from the issue description rationalizing this change: > Since GCAllocator is intended to be std.experimental.allocator's interface to D's built-in GC, it should match the...

> A no-op `deallocate` method does not free any memory, so having it return `true` would be lying to the caller. Yeah, well, not really? How do you define when...

> The DDoc comment describes it as "D's built-in garbage-collected allocator." That seems pretty unambiguous to me. I don't understand how you're reaching that conclusion just from that description. By...

That makes sense. So it comes back to, if the question is "can this allocator deallocate?", and the answer is "yes, but it's not going to happen right away", how...

Another reason I'm uneasy about this change: We have the following: - if a `deallocate` returns `false`, it means deallocation failed - a `deallocate` which always returns `false` is the...

~~Oh, I guess I should add that, since "a `deallocate` which always returns `false` is the same as no `deallocate`", it doesn't make sense to say that it's OK to...