Logging levels for Swift's server-side logging APIs and new os_log APIs

Evolution Pitches
19

@ravikandhadai/@jrose/@ben-cohen/@ktoso/@Michael_Ilseman/@tomerd/@dwaite/@hartbit/@dhoepfl Sorry to mention literally everybody on this thread but it has gone quiet for a while...

As you might know, we have adopted the proposed syslog levels for swift-log and we haven't heard anything that might suggest the proposed log levels might not be okay, so I think we're all good here :+1:.

I just have one question left regarding the 'numerical codes'. Should we really expose the log level as integral values? The reason I ask is: Before the switch to syslog log levels, swift-log used the numerical codes the other way around. So debug's numerical value was less than than error's whereas syslog has debug's numerical value greater than error's.

Now I don't want to discuss which system is 'right' or 'better' but I think with these two examples show that people seem to have different assumptions about log levels. After thinking about it, I would propose to completely hide the numerical value and to not offer the < operator/Comparable conformance and instead have only one function

extension Logger.Level {
    @inlinable
    func isMoreSevere(than: Logger.Level) -> Bool { ... }
}

It feels like everybody would agree that Logger.Level.error.isMoreSevere(than: Logger.Level.debug) should be true. Needless to say we'd still have the Equatable conformance.

Does that sound okay or do we feel we should also keep syslog's numerical codes?

5 Likes