-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Scoped sub-arenas #49
Comments
This crate is pretty much in maintenance-only mode, so I think it is best to leave new additions like this to external crates that either wrap and extend this crate, or fork it. |
What are the reasons for maintenance mode? Is there anything we can help out with for it to be more active? My interests are
I'm needing to use this in a threaded context where there isn't an explicit initialization phase like some libraries provide. I need borrows and For a community health perspective, it seems like it'd be best having us contribute to a shared implementation, rather than forking, so we all benefit from any |
I don't want to speak for other people who have been maintainers of this crate at times in the past, but lack of time/effort is the main thing for me. Organizing additional efforts around the crate is itself additional work for existing maintainers and adding new maintainers to an already-somewhat-popular crate (particularly new maintainers that one doesn't know directly or have a history of collaborating with) can be a little fraught what with potential supply chain attacks. So I'd personally prefer that someone fork this code base to revive it, rather than hand over the keys to this crate directly.
FWIW, you can always wrap it in a
You should be able to pass
|
Looks like I have no choice but to fork but I figured some context might be useful
Unless I made a mistake, I believe this needs
I believe this would mean an owned type is being returned by bumpalo while I need a borrowed type. I need the Arena to be responsible for dropping and not a proxy type. |
A feature that I would find useful is the ability to create scoped sections, where at the end of the section the arena will partially clear, dropping any allocations made in that section.
For example:
I implemented this in my fork of
typed_arena
-- the changes are fairly non-intrusive and don't touch theArena
type itself (but still, of course, rely on its implementation details).Would this feature be worth adding to the
typed_arena
crate? If so, I can make a PR.The text was updated successfully, but these errors were encountered: