Idea: push our collections to crates.io with allocator parameter, but don’t expose it from std
Fear of running into STL’s basic_string error messages
Can we put collections that take an allocator in core or alloc, and then std would not expose allocators?
what abour something like serde? how will it be generic over allocators? or Cloneing into an allocator/arena
type alias(with rustdoc help to make docs work well) won’t fall down in this scenario, where as literal new type wrappers in std would not
does std's stable sort take an allocator parameter for its scratch space?
do we want to make that a norm in the ecosystem?
more embedded use cases:
alloc in initialization phase, never dealloc
choose persistent vs ephemeral memory to allocate into
how can I call a function that doesn’t allocate?
many of these things require global knowledge: it isn’t jsut about this function, I need to ensure no one else does the bad thing either
would be nice to know if function that is parameterized by A: Alloc returns type that is allocated within A or not
should be reflected in the type
we should make it a goal that Vec works on no_std with a custom allocator type parameter
core versions have no default parameter, std versions do, and at the same time they are the same type still?
Can we special case diagnostics to replace BasicString<DefaultGlobalAlloc> with plain String?
If we had that plus the ability to set trait defaults for type aliases in std when it is defined in core, then we could do the type alias solution.
Rustdocs needs a way to have duplicated docs for type aliases, as if it was a new type and not an alias
this is something that would be useful in other scenarios as well
what do we need to stabilize anything?
fallible allocators?
allocator traits are fallible, collections methods are mostly not(yet?)
Topic: Per-collection allocators in std