This is a catch-all issue for our 2.0 wish list. If this list gets long and compelling enough, we'll consider cutting a new major version.

Copied from #387

Un-export Field internals

The original plan (see #13) with fields was to keep the implementation details completely private, and the only way to use a field would be to AddTo(Encoder).

It seems like FieldType is exported only to let the zap package expose field constructors, but I think what we should unexport all implementation details and instead:

• Expose the same field constructors in the zapcore package
• The zap package just wraps the underlying zapcore functions, and doesn't need access to the internals of a field.

This gives us more flexibility to change Field implementation details in future.

Unify the zap and zapcore packages

The intention here was to separate user-facing APIs from APIs relevant only to extension authors. Unfortunately, the division has only made things more confusing - in particular, separating the many zapcore.Field constructors from the type definition makes the GoDoc output quite daunting.

NB, we can probably fix this in Go 1.9 by moving all the code to the zap package and leaving aliases for exported identifiers in the zapcore package.

Configurable field order in the console encoder

Not everyone likes the order in the current console encoder. Making this configurable would be nice.

Copied from https://github.com/uber-go/zap/issues/387

Provide String method on Field

If a user tries to print fields, the output is pretty hard to understand, e.g.,

fmt.Println(zap.Error(errors.New("test")))

results in:

{error 25 0  test}

We should probably include a String method that returns easier to understand output.

Since the current field implementation exports the internals (https://github.com/uber-go/zap/issues/387), we can't add a String method until we unexport the internals.

Change zapcore.Core interface to split checking and adding core to the entry

I have been constantly having difficulties wrapping zapcore.Core to add what I needed.

Imagine I want to wrap a core to add filtering based on log entry. This would have to be done in Write since only there you know all the fields, which is what I needed. But checking whether to write an entry or not in Write is too late, because the wrapped core has already been added to the log entry in Check, because it not only checks, it also adds.

I encountered the same issue when I wanted to implement a core that would intercept level checking, i.e. to wrap a core to put an AtomicEnabler in front of it, which would enable me to dynamically drop the log level while not knowing the original LevelEnabler. This is also impossible AFAIK, because you have to call Check to add a core to every entry. But Check on the wrapped core always uses that core's LevelEnabler and it is not possible to replace it with my new AtomicEnabler.

zapcore.Core really sucks in this respect heavily, unless I am just unable to guess the right way how to do things...

glog has *Depth(...) functions that can log with caller's line information: https://github.com/golang/glog/blob/master/glog.go#L1060 Will be a very useful feature to add.

@AshKash That's supported via the AddCaller option in zap.

Add Binary support to ArrayEncoder

zapcore.ObjectEncoder supports logging binary blobs, but zapcore.ArrayEncoder doesn't. This isn't a huge problem, but it made https://github.com/thriftrw/thriftrw-go/pull/366 more complex (and less encoding-agnostic).

Support nil in Encoder interfaces

The ObjectEncoder and ArrayEncoder interfaces should support logging null values. Today, the only way to do this is via reflection, which isn't ideal for a strongly-typed API.

Copied from #630.

change go.uber.org to github/user-go/zap use private url instead github cause a lot of trouble, if 2.0 is breaking change , I suggest fix it.

Avoid checking the time where possible

Rather than eagerly calling time.Now, do this just before logging. This cuts the expense of debug logging significantly. See #664 for details.

Thanks to @fgrosse and @pjvds for suggesting this.

I would like to propose Support for logging contextual metadata #654.

Related to #753, if we ever decide to release a breaking change, we might consider opening up the nil type with a field type like zapcore.NilType, and adding AddNil() to interfaces like zapcore.ObjectEncoder.

Perhaps there's a method I'm not aware of, but I would like to introspect the current log level, to turn off expensive debug calculations:

func IsDebugEnabled() bool {...}

Perhaps there's a method I'm not aware of, but I would like to introspect the current log level, to turn off expensive debug calculations:

The underlying Core implements LevelEnabler which provides a Enabled(Level), so you can already do this in v1: logger.Core().Enabled(zap.DebugLevel).

Separately, this isn't a v2 request, but it something we could make easier in V1.

Add Trace level.

https://github.com/uber-go/zap/pull/933

Use generics with Field in go 1.18 to reduce the lines.

Another 2.0 item:

Drop ServeHTTP from AtomicLevel

This adds a dependency on net/http, which can inflate the binary size for CLIs and any other system that cares about binary size and doesn't need HTTP support.