SugaredLogger treats []byte fields as []uint8

[ansel1]

SugaredLogger turns all field values into zap.Any() fields. Unfortunately, zap.Any("key", []byte("value")) maps the []byte value to a zap.Uint8() field rather than a zap.Binary() field (because in golang, byte is just an alias for uint8)

It's all technically correct, but it leads to very unintuitive default behavior with SugaredLogger (and arguable, with zap.Any()).

A type switch cannot have a case for both []byte and []uint8, because they are just aliases of one another: the compiler won't allow it. But arguably, assuming the caller intended []byte will probably be correct more often that assuming the caller intended []uint8.

[akshayjshah]

Good point - I didn't think carefully enough about this when I wrote Any. Are you willing to open a PR that fixes this?

Also, we'll run into the same situation with []rune and []int32. I think that the current behavior of preferring integers is more intuitive there, so let's leave that as-is.

In case you weren't aware, also keep in mind that the sugared logger accepts strongly-typed Field structs too. If you need to get unblocked immediately, you can always

sugar.Infow("Failed to unmarshal JSON.", zap.Binary("raw", someByteSlice), "error", unmarshalingErr)

[ansel1]

sure, I can do that. So the fix plan is just swap out the []uint8 case in zap.Any() for a []byte case, plus update tests. on it.

[akshayjshah]

Yep, exactly. Let's also update the documentation comment for Any to clarify that we treat []byte and []uint8 as binary and []rune as []int32.

[akshayjshah]

Landed!