Skip to content
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 request: no-std + alloc #121

Closed
VorpalBlade opened this issue Mar 12, 2023 · 3 comments · Fixed by #127
Closed

Feature request: no-std + alloc #121

VorpalBlade opened this issue Mar 12, 2023 · 3 comments · Fixed by #127

Comments

@VorpalBlade
Copy link

I was looking through the code of this crate. I have a need for something like this on a no-std + alloc target, but it seems several features (such as using Cow from alloc) are missing. That should be possible to support.

@BurntSushi
Copy link
Owner

Can you say specifically what features you need? And also why you can't enable std?

@VorpalBlade
Copy link
Author

First: See my comment in issue #122.

Second: It is probable I could make do without Cow (my primary issue was #122, I just discovered this as well while investigating how difficult the limitations were and thought it would be nice to improve the API).

@BurntSushi
Copy link
Owner

Aye. Yes, this is definitely something we should do.

I believe the only API that's added with alloc is Finder::into_owned.

(I don't think there is any Cow in the public API of this crate, FWIW.)

BurntSushi added a commit that referenced this issue Jul 11, 2023
This crate currently only has a 'std' feature and of course support for
no-std. But in that mode, it was also no-alloc. In practice, this crate
is virtually all core-only, that is, no-std and no-alloc. There are
really only a few parts that want std or alloc. For std, runtime CPU
feature detection requires it. For alloc, there are a few minor APIs
that require allocation.

Previously, the only way to get the APIs that require allocation was to
enable 'std'. This new feature permits getting those APIs without
bringing in 'std'.

I don't expect this to unlock any new or interesting use cases, but it
will make downstream configurations a little more sensible and less
annoying.

Fixes #121
BurntSushi added a commit that referenced this issue Jul 11, 2023
This crate currently only has a 'std' feature and of course support for
no-std. But in that mode, it was also no-alloc. In practice, this crate
is virtually all core-only, that is, no-std and no-alloc. There are
really only a few parts that want std or alloc. For std, runtime CPU
feature detection requires it. For alloc, there are a few minor APIs
that require allocation.

Previously, the only way to get the APIs that require allocation was to
enable 'std'. This new feature permits getting those APIs without
bringing in 'std'.

I don't expect this to unlock any new or interesting use cases, but it
will make downstream configurations a little more sensible and less
annoying.

Fixes #121
BurntSushi added a commit that referenced this issue Jul 11, 2023
This crate currently only has a 'std' feature and of course support for
no-std. But in that mode, it was also no-alloc. In practice, this crate
is virtually all core-only, that is, no-std and no-alloc. There are
really only a few parts that want std or alloc. For std, runtime CPU
feature detection requires it. For alloc, there are a few minor APIs
that require allocation.

Previously, the only way to get the APIs that require allocation was to
enable 'std'. This new feature permits getting those APIs without
bringing in 'std'.

I don't expect this to unlock any new or interesting use cases, but it
will make downstream configurations a little more sensible and less
annoying.

Fixes #121
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants