The reason the void return type was left out previously was that it would cause too much trouble downstream for too little gain. I think @nicolas-grekas had a strong case against it.

However, I've been working with other codebases that used the void type consistently and I really like it. If we want to achieve 100% coverage with native return types as I proposed in #47551 (comment), using the void return type on a larger scale becomes inevitable.

👍🏻 from my side. I'll see if I can review the PR soon, but I'll probably do so in multiple sessions because my head will start to spin if I try to review it in one go. 🙈

We should particularly review if @final classes/methods didn't get real PHP void return types, as this is a BC break.

The formatter/handler/processor classes from the Monolog bridge are flagged @final, but native return types have been added there. I believe that this is still okay, but since you mentioned that case explicitly, I wanted to point it out. 🙂

I believe that this is still okay, but since you mentioned that case explicitly, I wanted to point it out. slightly_smiling_face

I think our policy is "when flagged with @final, it will be considered final on the next major". I.e. we should not treat them as final in the current major

I think our policy is "when flagged with @final, it will be considered final on the next major". I.e. we should not treat them as final in the current major

No, that's the case for classes that we annotate with @final since Symfony X.Y. On the next major, we either just remove this the Symfony version from the annotation or actually finalize the class.

With @final without a version, it's more like: "We consider this class to be final and if you extend it, you're on your own."

You might be saying the same thing :)
I verified the patch: no files with @final since ... are patched here, while some with @final are, which is fine since we don't consider this a BC break.

To elaborate a bit more on the @final case: I think that to some extend, we can be bold here. If someone knowingly extends a class that the framework considers to be final, they need to expect things to break in a minor release.

For classes flagged as @final since Symfony 6.X the case is different because at the time the developer created a child class our class might not have been documented as final yet.

That being said, we probably should be less reluctant with real final classes in 7.0. They allow us to move faster and force us to think about proper extension points. But that's off-topic for this PR.

In case you missed it, the patch failure in the 8.1 tests is fixed when #49346 is merged (and merged up into 6.3).

We review and patch methods on interfaces (like Symfony\Component\Mime\Header\HeaderInterface::setBody()) in a follow-up, don't we?

We review and patch methods on interfaces (like Symfony\Component\Mime\Header\HeaderInterface::setBody()) in a follow-up, don't we?

Yep, that's what I suggested in #47551 (comment)

Thank you @wouterj.

Thank you Nicolas for bringing these raw PRs in good shape in a 4 hour timeframe :)

And thanks to Alexander as well for spending a morning looking at : void and @return void :)