Guideline for logging in libraries

[dtolnay]

What sorts of things should be logged, what volume of logging is appropriate, and how to make it maximally flexible for the downstream application. Once log is 1.0, this may just be "use log."

[sfackler]

One thing we should note here is how to think about error levels. In particular, error! means "something has gone very wrong and someone should be paged".

[WiSaGaN]

It would be very hard to detail concrete guidelines for log meaning and format, which I think is itself a major topic. It also seems out of scope of an API guidelines.

Simple libraries can rely more on unit tests, and let user choose whether to log information or not. More sophisticated libraries indeed need some level of logging to help debug internal state. Maybe it should mostly be implemented in DEBUG level and TRACE level, but not INFO.

Making it opt-in like serde makes the logging non-intrusive for applications. User can specify feature log in dependency when they want logging inside the library.

• It helps maintain a consistent logging experience for application
• User does not need to pull in log dependency if they do not want to

The question for this approach is that how we can avoid writing conditional compiling directive in every log line.