|  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
Have you experienced this issue?
Rate the importance of this bug to you:

 [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: Mon Mar 04 03:01:30 2024 UTC