Runtime storage initialization about wee_alloc HOT 3 OPEN

So you're thinking that we make each imp module export a Backend trait (or whatever name) that provides the current "duck typed" module interface, but has access to &self?

trait Backend {
    fn alloc_pages(&self, pages: Pages) -> Result<NonNull<Opaque>, AllocErr>;
}

Then, you would generalize the static array backend to allow providing a slice of memory at runtime?

This would require threading T: Backend type parameters and members through everything, but that isn't too terrible, just write-once boilerplate.

The hard part would be if we tried to put Exclusive<T> as an associated type within the Backend trait. That would require generic associated types, unless I'm missing some trick. I guess we could leave that out of the trait, as it is now.

I'm a soft +1 to this proposal in general. What do other team folks think? cc @pepyakin @DrGoldfire @ZackPierce

from wee_alloc.

+1 from me. I like the idea of serving the general-purpose no_std allocator case better; I know there's demand in the embedded sphere for this sort of thing. As long as we're not regressing the wasm target, which it doesn't sound to me as if this would do.

from wee_alloc.

I generally like the idea of transforming the backend implementations to traits, though there are a few design details to work out. Off the top of my head,

• Should fn alloc_pages have access to &self or &mut self? [My guess: &mut self]
• How does this interact with the Exclusive code (as @fitzgen pointed out)?
• Does the ability to select backend by trait rather than compile-time-configuration-flags mean we should adjust our feature flagging strategy?

from wee_alloc.