<div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello Robbe,<br><br>Thank you for your response!<br><br>I was attempting to demonstrate how, like in log4j, providing an unsanitized input to a method and then executing it without allowing/facilitating any context specific validations is less safe. When I said less safe, I did not mean less safe than log4j, I meant less safe than separating it out into 2 method calls, like I demonstrated at the end of my email. I can see how that was confusing though, apologies.<br><br>And yes, ultimately, log4j was interpreting its inputs as a format. While that strongly resembles a potential failure case of LOGGER template, that was also not my intent. My intent was as simple as, put strings into a method, fail to perform adequate validations for aforementioned reasons, that causes problems. My point was that, when we realized that that method required validations later on, Rémi's idea would force us to validate on the low level inputs (etc., all mentioned in my original post) as opposed to the generated output that immediately gets logged. I understand how this too was unclear, apologies.<br><br>As for the Logger template, that's a really indirect way of doing things, so much so that I'd say it's worse than my suggestions. I didn't mention it because I think users would sooner validate on inputs or recreate the rich object creation rather than trying to validate on a third type - template. But even putting that aside, my point is that, by design, a Logger template is still encouraging side-effectual code, and thus, is encouraging the problems I mentioned in my original email. The only thing that either of our suggestions do is provide alternative ways to not take the easy path. But having a safe front door does not detract from the fact that there is a (more convenient) back door. One bad apple spoils the bunch.<br><br>And finally, yes, people will value convenience over safety, as always. Still worth calling out and criticizing when it happens -- especially when it's not just a blog on the internet, but a full blown presentation in front of several people that will likely color how they see this feature and its ideal use case. I ignored his original email last time, but if he doesn't even see what's wrong with it, then it really needs to be addressed.<br><br>Side effects are a dangerous default, and I think it's unwise to encourage them as a default for a feature whose biggest reason for existing is making safe interpolation convenient.<br><br>Thank you for your time!<br>David Alayachew<br></div></div>