Proposition 2: Adding types as static types is generally preferable. Unlike doc comments, static types are checked at runtime and thus guaranteed to be correct (as long as the code runs at all); the small runtime cost should be partially offset by performance improvements in newer PHP versions, and otherwise considered to be worth it. New code should generally include static types where possible, and existing code may have static types added as part of other work on it. I believe this describes our current development practice as MediaWiki developers.

I generally don't add return type declarations to methods that I add, and I have pushed back on CR requests to add them, except when the exception is reachable, i.e. a TypeError may actually be thrown if the class is misused by an external caller. The reasons for this are clutter and performance.

Clutter, because it's redundant to add a return type declaration when the return type is already in the doc comment. If we stop requiring doc comments as you propose, then fine, add a return type declaration to methods with no doc comment. But if there is a doc comment, an additional return type declaration just pads out the file for no reason.

The performance impact is measurable for hot functions. In gerrit 820244 I removed parameter type declarations from a private method for a benchmark improvement of 2%.

I would prefer to return the performance benefits of newer PHP versions to our users, rather than to fully consume them ourselves by increasing abstraction.

-- Tim Starling