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.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

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/