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

Add optional #[no_std] support #33

Closed
Robbepop opened this issue Nov 9, 2018 · 6 comments
Closed

Add optional #[no_std] support #33

Robbepop opened this issue Nov 9, 2018 · 6 comments

Comments

@Robbepop
Copy link
Owner

Robbepop commented Nov 9, 2018

The types provided by apint could be also available using libcore only.
Maybe we would need to cross-out some features but all in all it should be possible.

This issue proposes to add the std crate feature.
It is supposed to be enabled by default: default = ["std"]
Users can opt-in to use libcore instead of standard lib by importing apint without default features:

apint = { version = "0.2", default-features = false }

In this issue we can track which APIs shall be available to #[no_std] scenarios.

@Robbepop Robbepop changed the title Add optional #[no_std] support Add optional #[no_std] support Nov 9, 2018
@AaronKutch
Copy link
Contributor

I think in between the crate reorganization PR and the unchecked_internals PR I will do this and maybe fix up the error type too. Should we release a new version right after the reorganization PR or do we want to wait?

@AaronKutch
Copy link
Contributor

Or I could rebase the crate reorganization PR commits to include this since it is messing with imports anyway?

@Robbepop
Copy link
Owner Author

Or I could rebase the crate reorganization PR commits to include this since it is messing with imports anyway?

let us please do that in a separate PR.
as I have said I really want to keep PRs as small as possible for better reviewability and this one is already giantic.

I think it would be best to wait a bit for a release after the dust of all the new implementations and refactorings has settled down. Or what do you think?

@AaronKutch
Copy link
Contributor

I think it would be best to wait a bit for a release after the dust of all the new implementations and refactorings has settled down. Or what do you think?
Yes this is what I think

@Robbepop
Copy link
Owner Author

Implemented by #50.

@Robbepop
Copy link
Owner Author

Implemented. Closed.

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

No branches or pull requests

2 participants