log.Logger has an optimization where it detects when the writer is io.Discard and does no allocations. Maybe slog should do the same thing.

(CC @jba)

log.Logger has an optimization where it detects when the writer is io.Discard and does no allocations. Maybe slog should do the same thing.

I'm not sure this would work in this case, since this would be an implementation at the handler level, which would mean it would only apply to the standard lib JSON and KV handlers. It would require the user to take an slog.Handler and write something like:

if config.LoggingHandler == nil {
     //default: this JSONHandler does nothing
    config.LoggingHandler = slog.NewJSONHandler(io.Discard, nil)
}

// need the handler since slog.New(nil) will panic
logger := slog.New(config.LoggingHandler)

Which still feels pretty awkward.

I wouldn't want to make a nil *Logger meaningful. I think it would lead to hard-to-find errors where forgetting to set a logger resulted in no log output, and that is only detected when you need the log output (like during a production outage).

I think a slog.DiscardHandler variable would make sense, just as we have io.Discard. Or maybe NopHandler is a better name. Does that work for you?

I wouldn't want to make a nil *Logger meaningful. I think it would lead to hard-to-find errors where forgetting to set a logger resulted in no log output, and that is only detected when you need the log output (like during a production outage).

Concur. Either handler name works for me and, while I like NopHandler, I think it probably serves as more of a mnemonic to call it DiscardHandler in keeping with the convention elsewhere.

This would make the fallback story for logging injection something like:

type ClientConfig struct {
    Logger: *slog.Logger
}

func NewClient(config ClientConfig) (*Client, error) {
    if config.Logger == nil {
        config.Logger = slog.New(slog.DiscardHandler)
    }
    //...
    return &Client{
        logger: config.Logger,
    }, nil
}

Which isn't too bad, and makes a DiscardLogger() *Logger redundant, unless you really care about those 9 characters ;)

The only reason to prefer DiscardLogger() *Logger might be that it could be created fresh on invocation, which would prevent dependencies from mucking about with slog.DiscardHandler, though the flip side is that they can already call slog.SetDefault(), and it could be useful for debugging to explicitly set slog.DiscardHandler in main(). I guess it depends on your attitude towards package-level variables.

The proposal here is to add slog.DiscardHandler as a global variable, like io.Discard, or possibly a function.

It's ready for the proposal committee.

/cc @rsc

I want to cast a vote for this being added. I found myself writing the following today in a test suite because the portion of my application I was testing relies on having a logger instance, but I don't care about logs during the tests:

package main

import "log/slog"

type NullWriter struct{}

func (NullWriter) Write([]byte) (int, error) { return 0, nil }

func main() {
	logger := NullLogger()
	logger.Info("foo")
}

func NullLogger() *slog.Logger {
	return slog.New(slog.NewTextHandler(NullWriter{}, nil))
}

Reading through this thread I learned about io.Discard (I had searched for combination of "null" and "writer" but never would have guessed "Discard"). So that'll remove some code for me. But it would be really nice if we could invoke slog.NewNullLogger() or some such to avoid this sort of boilerplate.

@flowchartsman, can you edit your top post to refer to the actual proposal (#62005 (comment))?

@flowchartsman ... or just edit it to be the proposal.

Done!

Seeing this is not on track for 1.22, what should package authors do in the meantime, in case they want to provide structured logging as an optional feature?

• Implement their own no-op loggers, or
• Require users to pass a *slog.Logger (which isn't harmful per-se but can add undesirable friction)

I'd assume that a gradual ecosystem-wide migration to slog starts with package authors adding support first, enabling downstream projects to flip the switch at some point in the future.

Added https://go-review.googlesource.com/c/go/+/548335 which uses @bcmills example to demonstrate how users can solve this, for now.

Change https://go.dev/cl/548335 mentions this issue: log/slog: add example showing how to discard logs

Change https://go.dev/cl/547956 mentions this issue: log/slog: implement slog.Discard with example

I've gone ahead and submitted change 547956, just to get the ball rolling. It required I rename the internal discardHandler, (which is similar, but also allows for initialization to test allocs) to nopHandler, which is a fitting use for the discarded name, IMO, and I've gone with slog.Discard for brevity and symmetry with io.Discard, but am happy to amend.

It seemed appropriate to make a whole file example demonstrating its usage in type initialization, since the initial purpose of the proposal was to have a sensible fallback handler that types which consume a *slog.Logger could use when none is provided. Hopefully this also helps illustrate that types should accept loggers, rather than generate them.