|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #71058 Function prototypes reflecting parameter/return type declarations
Submitted: 2015-12-08 11:48 UTC Modified: 2020-08-14 13:53 UTC
From: Assigned:
Status: Open Package: Documentation problem
PHP Version: 7.0.0 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
New email:
PHP Version: OS:


 [2015-12-08 11:48 UTC]
Given that PHP 7 introduced return type declarations and scalar parameter declarations, there is a conflict between the function prototypes used in the manual and the prototypes used in code. This has already caused some confusion (e.g. bug #71051 where someone tried to override a method using the "type suggestion" from the documentation).

This request is in two parts (which may become separate requests at some point):

1. Discuss and decide how to approach the issue of the manual stating that an argument should be of a certain type, but is not really part of the function signature.  The suggestion here is to have clearly marked prototypes stating whether the type declarations are "suggestions" as they have historically been, or actual declarations.  

2. Consider altering the function prototype to move the return type declaration to the end, in order to match PHP syntax.  This does not come without issues; such as our "mixed" pseudo-type.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-12-08 11:54 UTC]
See also the phpdoc mailing list thread "Changing our function definition syntax in the manual" --
 [2015-12-19 16:51 UTC]
More formally, the problem is the distinction between type declarations (internally still called "type hints"), and zend_parse_parameters (ZPP) types. Very few internal functions use type hints, they usually have untyped parameters that are handled by ZPP instead.

At least ZPP and type hints behave mostly the same, with the exception of NULL handling. Obviously it's still a problem for inheritance, though.
 [2020-02-16 16:48 UTC]
This requested was addressed, right?

We are now using the syntax `{modifiers} {method_visibility} {(function/method)_name} ({list_arguments_with_type}) : {return_type}`

 [2020-08-14 13:53 UTC]
Item 2 has indeed been addressed in the meantime.

Item 1 might best be deferred to PHP 8, where most internal
functions already have been overhauled to have meaningful arginfo
structures (generated from *.stub.php files).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Feb 21 19:01:29 2024 UTC