github-actions[bot] on gh-pages
API Guidelines @ rust-lang/api-… (compare)
KodrAus on master
Update mdbook Merge pull request #233 from eh… (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?
Foowhich uses a
Bar, but also returns a
Bazalongside the Foo (as in, a
Result<(Foo, Baz)>). How should one name this method?
nifticrate. 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
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!