<https://github.com/status-im/nim-chronicles> supports similar ideas around compile-time enabled logging and loggers, removing the logging code when not used (with lots and lots of fancy options and ways to create compile-time configurations).
In practice however, compile-time based logging doesn't work very well, for several reasons: * when you introduce logging, the public API tends to suffer - logging creates an "out-of-band" channel through which information is returned and if you also return it in the API, you've created API duplication, which rarely ends well (two ways to achieve the same result) * logging is a side effect: if you compile-time-disable logging, you're creating a different execution flow for the non-logging version of the library - at first, this seems like a great idea, but soon these side effects become significant to the correct function of the application / library, and you end up not using the fancy logging magic you spent so much time on perfecting - it instead becomes a source of bugs and frustration * you create multiple versions of your codebase - testing becomes difficult because now you have multiple versions to test (does the code still compile with "trace" logging? does it work with json? etc) * your users come to expect logging to work in a particular way - however, relying on imports, or even worse, order of imports, for log formatting in general is a really, really bad idea because the formatting will be different depending on which imports you remembered to make * your users typically really want to configure logging for themselves without recompiling the application - this requires a certain amount of "runtime" behavior, and again, all that fancy compile-time magic you invented is .. lost what is really useful about chronicles is its support for structured logging, and the smooth syntax it has for achieving it - when outputting JSON to an ELK stack, you can run analysis on logs over time etc which is a great debugging help. Regarding logging vs API richness, it really depends on the type of library - API richness is good for a number of reasons but often onerous to get right - logging provides a shortcut and is excellent for "business logic" (as opposed to abstract data types, algorithms etc). Often, you might start out with logging then slowly push the logging out of the core logic and into the UX/busniess logic part of your application.
