https://paper.dropbox.com/doc/API-Guidelines-bDAAOER4WHdxJ1XtEAFYs
github-actions[bot] on gh-pages
API Guidelines @ rust-lang/api-… (compare)
dtolnay on master
C-DTOR: Clarify that `Drop` sho… Merge pull request #263 from jo… (compare)
github-actions[bot] on gh-pages
API Guidelines @ rust-lang/api-… (compare)
joshtriplett on master
Replace "task failure" with "pa… Merge pull request #261 from Pa… (compare)
github-actions[bot] on gh-pages
API Guidelines @ rust-lang/api-… (compare)
dtolnay on master
Update GitHub Actions actions/c… Merge pull request #262 from dt… (compare)
Hi, not sure if this is a proper place to ask, but i'm looking for some "insight"s and guidelines of the trait system.
What kind of roles should traits play? I've seen adjectives "Sized", nouns "Future" "Sync", verbs "Send" "Convert" "Borrow", prepositions "From" "To" "AsRef". Not to say some people are even abusing trait inheritance trying to build type taxonomy using trait inheritance. Are traits truly neutral to these usages? Or should there be some guidelines for when and how?
Foo
which uses a Bar
, but also returns a Baz
alongside the Foo (as in, a Result<(Foo, Baz)>
). How should one name this method?
nifti
crate. Reading a .img file here should yield a header extension sequence followed by the actual volume data. https://docs.rs/nifti/0.3.1/nifti/volume/inmem/struct.InMemNiftiVolume.html#method.from_file_with_extensions
Hi guys,
I have a question about guidelines on use of errors in the API of a library.
I’m developing a library in Rust and, naturally, it has to return errors from its API.
I followed C-GOOD-ERR advice and created error types specific to my domain (some of them are structs, some enums).
However, during the code review I was told that I’m doing it wrong, C-GOOD-ERR is legacy, API guidelines are outdated and what I should do is to replace my struct/enum errors with ad-hoc strings inside Result#context("error message").
I tried to argue that Result#context("error message") is complementary and cannot be a substitute for structured errors, especially when returned by the library. But, again, I’m told I’m wrong.
Could you please help me understand why struct/enum errors are wrong ?
Is Result#context(“error message”) indeed a substitute for them ?
Are you planning to update guidelines to favour Result#context(“error message”) over typed errors ?
Thanks in advance!