Consider making the Stringers function generic?

[fgimian]

Hey there, would you consider making Stringers generic similar to zap as seen at https://github.com/uber-go/zap/blob/master/array_go118.go#L145 ?

This would make it possible to pass a slice of any type which implements String() as opposed to having to allocate a new slice of fmt.Stringer in the current implementation.

I believe the behavioural change won't be a breaking change for existing users and only make the function more flexible, but it will mean that Go 1.18+ would be required.

Please let me know what you think 😄
Fotis

[IDisposable]

@rs any opinion on this? I could easily add struggle fruitlessly with this if desired.

[IDisposable]

I dove into this a bit, and unfortunately go doesn't consider those slices as identical types so we really have to allocate an array and copy the entries. I created generic helper methods in global_118.go zerolog.AsLogObjectMarshalers and zerolog.AsStringers if you're using go 1.18 or later (where we can have generic helper methods).

In validating this, I did add support for the use-case where you have a list of objects that implement the LogObjectMarshaler or fmt.Stringer interfaces, but not in an array (something that occurs in my logging uses), so I added the syntactic sugar methods ObjectsV and StringersV and also StrsV that are variadic so you can pass an explicit list without needing to explicitly create the array in your own code. They are suffixed with V to ensure they aren't a breaking change.

All of these changes are in PR #752 which has test coverage as well.

[IDisposable]

Note that in theory it would be nice if go let declare methods (not free functions) that are generic, but for some reason they don't

func (e *Event) Objects[T LogObjectMarshaler](key string, objs []T) *Event {
	///
}

method must have no type parameters

The reason this works in zap is that all the field functions are free functions, not methods (against *Event or Context as in zerolog)