php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: salathe@php.net
New email:
PHP Version: OS:

 

 [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-08 20:24 UTC] requinix@php.net 
Related To: Bug #71051
 [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: Thu Nov 21 15:01:30 2024 UTC