Allocator Part of Type

[Steven Schveighoffer]

On 3/15/18 3:36 PM, jmh530 wrote:
> I recall some talk Andrei did where he said it was a bad idea to make 
> the allocator part of the type.  However, the container library in 
> dlang-community(says it is backed with std.experimental.allocator) 
> contains allocator as part of the type. Automem does too. Honestly, I 
> would think you would really be hobbled if you didn't. For instance, if 
> you want to expand a DynamicArray using the built-in ~= operator, then 
> you really need to know what the allocator is. Without ~= you'd have to 
> rely on functions (maybe member functions, maybe not).
> 
> So I suppose I'm wondering why is it a bad thing to include the 
> allocator as part of the type and why is it that it seems like in 
> practice that's how it is done anyway.

I don't know if I've heard Andrei talk about that, but I definitely have 
made it part of the type for types that need to allocate. The only other 
possibility is to accept and use an Allocator object (i.e. the interface).

I suppose the main reason you may want to not make it part of the type 
is if you want to compare/assign two types built with different 
allocators. But then I don't know why you would want to do that.

But I just thought of this too -- maybe he said you should make it a 
part of the struct itself? That is, you shouldn't make the allocator a 
member, but the allocator itself can be part of the type?

Not sure.

-Steve