@johannesweiss @IanPartridge It is great to see the progress on the server-side logging API design, and the discussions here. As we (@Ben_Cohen, @moiseev, @Devin_Coughlin and I)
are working on improving the Apple's OS logging API of Swift, there appears to be a lot of synergies in the ideas and goals between these proposals. We think it would be great if we can keep open the possibility of making these APIs source-level compatible in the future. Just wondering if we can think about and smooth out some of the divergences that are likely to affect compatibility or hinder flexibility in the future.
One specific question we have is whether it is better to use custom string interpolation in place of strings in the server-side logging API. Currently, log functions such as log, trace, debug, info are accepting Strings. Accepting a custom string interpolation type (similar to what we plan to do for os_log) will offer more flexibility in the future. Initially, the custom string interpolation can just build strings (like DefaultStringInterpolation), but they can be customized in the future. Some benefits of using a custom string interpolation type are
-
It enables specifying formatting options, in addition to what is supported by
DefaultStringInterpolation, for interpolated values. E.g. like specifying precision with floating-point values, using hex/octal notations etc. It could also support rending options specific to a logging backend. -
It can potentially enable many compiler optimizations, which are much easier to do when the static and dynamic parts of the string interpolation are not combined together. In fact, this also relates to @IanPartridge's comments on eliminating compile-time overheads when logging is disabled. These kind of optimizations are something that we plan to do for
os_logAPIs, and they are possible because of custom string interpolation. -
It is easier to introduce and customize privacy policies. Some parts of the interpolation can be treated as private. It also enables localization .
-
They provide an elegant way to extend and customize the log APIs to custom types. For instance, the author of a library or framework can extend the string interpolation type and add support for logging their types. They can also implicitly attach metadata and tags, while hiding it from the users of the log calls. (This OS Log proposal provides an example of extending that API to log a user-defined type
Developer.)
Also, it is better to avoid overloading the APIs to accept a custom string interpolation type (in the future), as the compiler should then make a choice between using the DefaultStringInterpolation type vs the custom string interpolation type on seeing a string interpolation. To enforce a particular behavior users of the logging API have to add explicit types to the log messages (or do type casting) at all places, which is potentially error prone. It seems like it is better to make this choice of using custom string interpolation vs strings upfront.