The code seems correct, but append can behave strangely, when it does not have to grow in size, i.e. the returned pointer is the same as the first argument.
Code on playground demonstrating the problem: https://play.golang.com/p/ALsrKvYmt3s
In the first part of the code I show the general problem, with a plain int array, where it is unexpected that b and c both contain a 4, instead of b with a 3.
And the same applies to zerolog hooks. Once they are at a threshold where the capacity of the hooks array is large enough, I can create a sub-logger called logger1 with an additional hook, and it works fine.
Then I create another sub-logger called logger2, with a different hook, and logging still looks fine.
Using now logger1, prints the hook of logger2, which is not the desired behaviour.
I fear that a full deep copy must be done to avoid this kind of behaviour.
This line is relevant: https://github.com/rs/zerolog/blob/9070d49a1a4154c819e9c5ae6c923f3cc916d959/log.go#L312
The code seems correct, but
append
can behave strangely, when it does not have to grow in size, i.e. the returned pointer is the same as the first argument.Code on playground demonstrating the problem: https://play.golang.com/p/ALsrKvYmt3s In the first part of the code I show the general problem, with a plain int array, where it is unexpected that
b
andc
both contain a 4, instead ofb
with a 3. And the same applies to zerolog hooks. Once they are at a threshold where the capacity of the hooks array is large enough, I can create a sub-logger called logger1 with an additional hook, and it works fine. Then I create another sub-logger called logger2, with a different hook, and logging still looks fine. Using now logger1, prints the hook of logger2, which is not the desired behaviour.I fear that a full deep copy must be done to avoid this kind of behaviour.