php.net |  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: salathe@php.net Assigned:
Status: Open Package: Documentation problem
PHP Version: 7.0.0 OS:
Private report: No CVE-ID: None
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 !
Your email address:
MUST BE VALID
Solve the problem:
26 + 29 = ?
Subscribe to this entry?

 
 [2015-12-08 11:48 UTC] salathe@php.net
Description:
------------
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.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-12-08 11:54 UTC] salathe@php.net
See also the phpdoc mailing list thread "Changing our function definition syntax in the manual" -- http://php.markmail.org/thread/4rj5yj5czqxjt6uo
 [2015-12-19 16:51 UTC] ajf@php.net
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] carusogabriel@php.net
This requested was addressed, right?

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

Example: https://www.php.net/reflectionmethod.invokeargs
 [2020-08-14 13:53 UTC] cmb@php.net
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: Tue Oct 08 02:01:28 2024 UTC