Patrick Ohly

> does the cost of Logger getting bigger matter? The approach where Logger is smaller is a bit faster in traditional benchmarks that rely on copying Logger and slower in...

I force-pushed with the changes discussed above and also added one new commit for Discard: it might be useful to keep it unchanged also when WithContext and WithContextValues are called...

I have added several commits at the end to support logging of context values with helper functions. I'll continue with performance investigations. As it stands now, this API is sufficient...

> This PR now carries multiple ideas, which probably deserve their own PRs to consider. Yes, it has become my playground for everything that might change the logr API because...

I think I have found an approach that minimizes the size of Logger and allows caching of the context retrieval + WithValues - see the last two commits. Performance seems...

> DiscardWithName() is suspicious. I'd like to understand that. This is because of the additional `l.sink == discardLogSinkInstance` comparion. The test case is so fast at 2.24ns that it matters....

I have updated the PR with changes as discussed so far, except for adding examples. The last four commits implement different possible solutions: - no caching, everything in Logger except...

When is slog going to be stable enough to use it as logging API in Kubernetes? I agree that the end goal should be to use slog in Kubernetes libs,...

That makes sense. We need to understand a possible timeline before we can decide whether adding new features is still needed.

Let's not pursue this further.