Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

ark_std::error vs core::error #44

Open
burdges opened this issue Apr 2, 2023 · 3 comments
Open

ark_std::error vs core::error #44

burdges opened this issue Apr 2, 2023 · 3 comments

Comments

@burdges
Copy link

burdges commented Apr 2, 2023

ark_std::error replaces core::error when not using std, but it winds up woefully inferior to the core::error behind #[feature(error_in_core)]. In particular ark_std::error::Error should've the downcast* methods on core::error::Error.

We should probably copy core::error to ark_std::error. Ain't much relevant in the real std::error anymore. If possible, we should detect #[feature(error_in_core)] or even nightly, so as to not replace core::error then.

Interestingly, there were never std::io references in std::error per se. It appears backtrace messed up moving std::error to core::error, but I've no idea why backtrace cannot work with just alloc, or be placed into an extension trait, or whatever.

@burdges
Copy link
Author

burdges commented Apr 13, 2023

@Pratyush
Copy link
Member

100% agree that we should switch to core::error, but as things stand this is not actionable, right? We need error_in_core to be stabilized first. I would prefer to avoid rust version detection, as that would involve a build.rs which worsens compile time.

@burdges
Copy link
Author

burdges commented Apr 13, 2023

I simply meant copy "more of" std::error from std into ark-std, specifically the <dyn Error>::downcast part.

I'll make @achimcc submit a PR for it if our auditors think error passing matters in ark-scale link above. We've correct error passing in the substrate host already, which maybe enough.

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

No branches or pull requests

2 participants