Hi @Trismegiste!
I see this is your first PR and I must say it looks very complete! Thanks for putting in the time to start contributing 💚 .

Unfortunately, we've rejected changes like this in the past: #14682 There are, imho, two reasons for this:

1. Performance in this class is critical (it is called at the front of every request within the firewall, most often every request in the application). We sometimes have to give up clean code for performance matters in these critical places.
2. Symfony is very conservative with changes. In the past, we've learned that minor changes that didn't seem to have any impact can lead to broken applications after an upgrade. The last thing we want is breaking production apps after upgrading from 5.4.x to 5.4.(x+1).
   This means that everything that is not 100% clear a bug fix is often considered a feature (and thus included in the unstable branch, 6.1 at the moment). However, with changes like this, the value of the change is not existent (for the end user). In those cases, it's often better to not do the change at all.

So my vote would be 👎 here, unfortunately.

If you want to contribute to Symfony, but aren't sure what to do, feel welcome to join the #contribs channel on Symfony slack. Maybe we can find a nice issue or feature for you to work on :)

PHP 8 allows a null safe operator ;)

alernatively we do $this->logger && $this->logger->... here and there i believe

Hello @wouterj , thank you for your fast reply

Performance in this class is critical (it is called at the front of every request within
the firewall most often every request in the application). We sometimes have to give up
clean code for performance matters in these critical places.

I completely understand 👍

This means that everything that is not 100% clear a bug fix is often considered a feature (and thus included
in the unstable branch, 6.1 at the moment). However, with changes like this, the value of the change is not
existent (for the end user). In those cases, it's often better to not do the change at all.

I also agree with the « if it ain't broke, don't fix it » 😉

Anyway, thank you for your explanations, that's very kind ❤️

Closing as explained, can't wait your next PR @Trismegiste :)