-
Notifications
You must be signed in to change notification settings - Fork 385
New error type #2500
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
base: main
Are you sure you want to change the base?
New error type #2500
Conversation
Also the change on the shell files is very smol (just replacing |
Even the |
Probably typo'd when executing. Taking care of it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very neat that we can simplify the error type like that!
#!/bin/bash | ||
#!/usr/bin/env bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a fellow NixOS user (not on the work laptop though), I salute you 🫡
contracts/hackatom/src/errors.rs
Outdated
Std(#[from] StdError), | ||
Std(StdError), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we not use #[from]
anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because of the requirement of thiserror
. If you want to use the #[from]
feature, it has to implement core::error::Error + Send + Sync
(which we can't fulfill because of trait blanket impls; same reason why anyhow can't implement the error trait)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that's a bit sad. What if we used manual (or macro assisted) impls for all our error types instead of the blanket impl?
// "mom, can we have specialization?" | ||
// "we have specialization at home" | ||
// specialization at home: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😆
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
Co-authored-by: Christoph Otter <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just a changelog entry needed
Now with 99% less enum cases. Add that to the cerial packaging as a selling point.
Closes #2469