- Version: 0.1
- Date: 2013-06-26
- Author: Florin Patan
- Status: In draft
- Patch included: NO
The scope of this RFC is to add support for function / method return typing system.
Given the fact that more and more people use PHP every time they want to start working on their applications and that PHP is no longer used only for simple website creations, code quality should come to mind when creating those applications.
As such, one of the missing features of PHP is a return typing system which would allow users to specify a strict return type for functions and methods.
This feature would allow for improvements in the produced code quality as once you declare the return type of a method in a interface for example.
Third party tools could also benefit from this as they could try and track the return type and provide code insights when the returned value doesn't match the specified type.
Further improvements could be possible as knowing the returned type could be useful for a multi-level opcode cache system.
The proposed structure would look like this:
[method_attributes] function [<return_type>] [method_name] '(' parameters ')'
Basically we should allow for every type in php to be returned, not just the types allowed for parameter typing. As such, the following types should be supported out of the box:
- boolean
- int
- float
- string
- array
- object
- resource
- NULL
- callable
- interface
- class
If no return type is specified the the parser should act like it acts currently, ignoring any typing.
There should be no implicit conversion allowed.
Although this is contrary to PHP type juggling, having return typing is meant to prevent this juggling as well.
function <int> add($a, $b) {
return (int) ($a + $b);
}
interface DemoInterface {
public function <mysqli> getDriver();
}
class Demo implements DemoInterface {
public function <mysqli> getDriver() {
return new mysqli('localhost', 'my_user', 'my_password', 'my_db');
}
}
Strictly relying on return type while using libraries outside of user control could result in having serious code issues so when used for direct usage. As such, the best way to use this would be in combination with parameter hinting.
- Improves code quality.
- Improves tooling support.
- Possible further improvements in data handling / code speed execution.
- Minor/negligible performance impact when used
- Not performing additional checks in userland could render to serious issues in code when relying to libraries outside of user control.
- Possible other changes caused by changing the parser
None yet.
None yet.
This proposal is inspired from previous work of Will Fitch [email protected] which can be found here: https://wiki.php.net/rfc/returntypehint2
- 0.1 Initial proposal