std.allocator ready for some abuse

[John Colvin]

On Friday, 25 October 2013 at 01:00:04 UTC, Michel Fortin wrote:
> On 2013-10-25 00:20:41 +0000, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
>
>> If that happens, perhaps AffixAllocator!(A, size_t) could be 
>> of use by sticking the allocated size just before the 
>> allocation. But then you have a different problem - tapping 
>> into possibly cold memory when deallocating.
>
> The size is already available in the classinfo, but the 
> underlying allocator doesn't need it when deallocating (the 
> size part will get ignored). The goal is to not have to give 
> the size to deallocate when it doesn't need it (to save you 
> from retrieving it). All you need is to know that deallocate() 
> ignores the size part of the given array telling you whether or 
> not it's safe to call deallocate(pointer[0..0]). You could add 
> an optional "deallocateIgnoresSize" property for that.
>
> By the way, I think the idea of adding a boolean property for 
> this offers less room for misuse than adding an optional 
> deallocate(void*b) overload. With an overload you're 
> duplicating the API and it won't be immediately clear whether 
> or not it's best to provide the size.
>
> But I'm still not sure it's worth the trouble. I'll leave 
> others be the judge of that.

A void deallocate(void* b) overload might be good in these cases.