|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #80921 allow parameter type hints for poorly typed interface methods
Submitted: 2021-03-30 20:31 UTC Modified: 2021-03-30 20:51 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: smiley at chillerlan dot net Assigned:
Status: Wont fix Package: Class/Object related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
36 - 13 = ?
Subscribe to this entry?

 [2021-03-30 20:31 UTC] smiley at chillerlan dot net
Hello! I'd like to be able to add parameter type hints for poorly typed interface methods for type security and consistency.

We're currently allowed to add return types in case they're not declared in the interface or omit existing type hints in the interface, but for some reason the aforementioned probably most important feature is missing.

A userland example would be the dilemma of a PSR-7 update:

I understand that this might require an RFC, but i don't possess neither the technical insight, nor the mental capacity to start such a process.

Don't mind me if plans/feature request for such an update already exist. :)

Test script:

// a poorly typed interface
interface PoorlyTypedInterface{
	public function methodWithoutTypeHints($string, $int);

// currently we're only allowed to add a return type
class PoorlyTypedClass implements PoorlyTypedInterface{
	public function methodWithoutTypeHints($string, $int):array{
		return [$string, $int];

// proposal: allow adding parameter type hints
class StronglyTypedClass implements PoorlyTypedInterface{
	public function methodWithoutTypeHints(string $string, int $int):array{
		return [$string, $int];

Actual result:
Fatal error: Declaration of StronglyTypedClass::methodWithoutTypeHints(string $string, int $int): array must be compatible with PoorlyTypedInterface::methodWithoutTypeHints($string, $int)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2021-03-30 20:51 UTC]
-Status: Open +Status: Wont fix
 [2021-03-30 20:51 UTC]
No parameter type means "mixed", as in any type is accepted. Allowing a child class like StronglyTypedClass to be more restrictive about its *parameter types* violates LSP and the principle of contravariance. *Return types*, on the other hand, can be made more restrictive.
 [2021-03-30 20:52 UTC]
Changing parameter types to allow a more specific type opposes the Liskov Substitution Principle.

Contravariance states parameter types of a child class method can be less specific than its parent class method.
 [2021-03-30 21:07 UTC] smiley at chillerlan dot net
Thank you for the quick reply! I understand the general problem with LSP, however, the problem i see with PHP is that (scalar) type hints didn't exist before 7.0 and a lot of userland interfaces therefore technically cannot adhere to LSP (even though types may be declared in docblocks). In the example case of PSR-7, implementors are left with countless type checks that could be avoided if it was possible to add type hints.
 [2021-03-30 21:24 UTC] yvdg dot sgegeg at sgeg dot hh
"No parameter type means mixed" makes it that idiotic because a specific type in an extended class is compatible

this behavior makes it impossible to prepare the implementation of type hints in base classes by first add them to extended classes

and no in the real world you can't always deploy everything atomic 

frankly without that limitation you could state in the documentation that every extended class has to implement native type hints based on the existing phpdoc because release xyz or the baseclass will have them too
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Mar 28 13:03:41 2023 UTC