@richard67 what do you think of this?

definitely can't be done in 4.0 at this late stage

definitely can't be done in 4.0 at this late stage

Would it be possible for 4.1?

definitely can't be done in 4.0 at this late stage

May I ask why? It's just type-hinting, the return or the arguments are already expected to be a specific type and this PR just forces what should have been the default

May I ask why? It's just type-hinting, the return or the arguments are already expected to be a specific type and this PR just forces what should have been the default

Because anyone with a custom router (i don't know if it's still the case but pretty sure e.g. kunena had at one point) will have a b/c break :( PHP throws static if you don't have the same type declaration in child classes.

The API part is brand new code so it could be done at least there

The API part is brand new code so it could be done at least there

Like I said there's php notices thrown if the parent class doesn't match with the child class. You can't just do it in the API. Has to be the parent Router class and all it's children or nothing. That's why adding in typehints across core is going to be so painful on the "old" pre-4.0 classes

... and why it cannot be done at this moment in time with a release caandidate

Should this be tested?

@Quy I've resolved the conflicts here

This pull request has automatically rebased to 4.2-dev.

This pull requests has been automatically converted to the PSR-12 coding standard.

I'm going to close this one as it is not possible to add typehinting to existing library classes, because it is not possible to have a transition period. It is an all or nothing backwards compatibility break. What you can do is to create new functions with the typehinted arguments and deprecate the old ones.