Ah, I see. For logging, the `log` crate[1] provides the interface that libraries can use, which defines macros for each log level. For partial success/failure

Ah, I see. For logging, the `log` crate[1] provides the interface that libraries can use, which defines macros for each log level. For partial success/failure, I actually don't think there is much convention. On the one hand, you might consider logging as sufficient enough, depending on your use case. In some cases, I have adopted a form of partial errors. That is, instead of: fn foobar() -> Result<Value, Error> { ... } I use fn foobar() -> (Value, Option<Error>) { ... } You can see an example here: https://docs.rs/ignore/0.1.9/ignore/gitignore/struct.Gitignore.html#method.new https://docs.rs/ignore/0.1.9/ignore/gitignore/struct.Gitigno... And in particular, the error type is a recursive structure, which permits it to store an aggregation of errors: https://docs.rs/ignore/0.1.9/ignore/enum.Error.html https://docs.rs/ignore/0.1.9/ignore/enum.Error.html Since this isn't something people need too often, the syntactic overhead of this approach is considerably clunkier, so I definitely wouldn't want this to be a pervasive part of a library. Nevertheless, if you can get both a success value and an error value, then your return type is inherently a product, not a sum, which is at odds with the `Result` sum. [1] - https://docs.rs/log/0.3.7/log/ https://docs.rs/log/0.3.7/log/