# PHP RFC: Single-Expression functions - **Version:** 1.0 - **Date:** 2025-05-22 - **Author:** Dmitrii Derepko, xepozzd@gmail.com - **Status:** Under Discussion - **First Published at:** https://wiki.php.net/rfc/single-expression-functions - **Implementation:** https://github.com/php/php-src/pull/17677 ## Introduction This RFC proposes an alternative syntax for single-expression functions using the `=>` operator instead of curly braces and explicit `return` statements. This syntax provides a concise way to declare simple functions without the overhead of traditional function body syntax. ## Proposal This RFC introduces a shorthand syntax for functions that consist of a single return statement. The proposed syntax uses the `=>` operator to denote that the function directly returns the result of the expression. ### Reasoning Modern codebases typically contain numerous entities, models, forms, data transfer objects (DTOs), and value objects (VOs) with many getter and setter methods. These methods are usually simple one-liners that create significant cognitive overhead with minimal functional value. Concise syntax makes it easier to associate function names with their return values, reducing mental parsing overhead. #### Current Syntax Problems PSR-compliant syntax requires multi-line formatting: ```php function getName() { return "Name"; } ``` Even compact syntax contains redundant elements: ```php function getName() { return "Name"; } ``` #### Cognitive Processing Analysis When reading traditional function syntax, developers mentally process: ```php function getName() { return "Name"; } ``` The brain performs this parsing: - `function` - skip (boilerplate) - `getName` - identify function purpose - `()` - note no parameters - `{` - skip (boilerplate) - `return` - skip (expected keyword) - `"Name"` - identify return value - `;` - skip (boilerplate) - `}` - skip (boilerplate) Effectively, the brain extracts: ```php getName() "Name" ``` This syntax directly represents the mental model: function maps to value, making the code more readable and reducing the cognitive load required to understand simple getter/setter methods. ### Syntax ```php function functionName(parameters): returnType => expression; ``` This is functionally equivalent to: ```php function functionName(parameters): returnType { return expression; } ``` ### Examples Basic function: ```php // Short syntax function getVersion(): int => 1; // Equivalent traditional syntax function getVersion(): int { return 1; } ``` Function with parameters: ```php // Short syntax function add(int $a, int $b): int => $a + $b; // Equivalent traditional syntax function add(int $a, int $b): int { return $a + $b; } ``` Class methods: ```php class Calculator { // Short syntax public function multiply(int $a, int $b): int => $a * $b; // Equivalent traditional syntax public function divide(int $a, int $b): float { return $a / $b; } } ``` ## Backward Incompatible Changes This change introduces no breaking changes. The proposed syntax would currently result in a parse error, making it safe to implement. ## Proposed PHP Version(s) PHP 8.5 ## RFC Impact ### To SAPIs The implementation is purely lexical—during parsing, the short syntax is transformed into the equivalent traditional syntax before further processing. This ensures no impact to SAPIs. ### To Existing Extensions Nope. ### To Opcache Implementation does compile-time changes that do not affect Opcache. ### New Constants Nope. ### php.ini Defaults Nope. ## Open Issues Make sure there are no open issues when the vote starts! ## Unaffected PHP Functionality Parent scope won't be captured as arrow functions do. Current RFC do lexer/parser modification allows to shorten typical code. ## Future Scope This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC. ## Proposed Voting Choices Include these so readers know where you are heading and can discuss the proposed voting options. ## Patches and Tests Links to any external patches and tests go here. If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed. Make it clear if the patch is intended to be the final patch, or is just a prototype. For changes affecting the core language, you should also provide a patch for the language specification. ## Implementation - [Pull Request / php-src](https://github.com/php/php-src/pull/17677) ## References - [Original Short Functions RFC](https://wiki.php.net/rfc/short-functions) - [Arrow Functions RFC](https://wiki.php.net/rfc/arrow_functions_v2) - [Pipe Operator RFC](https://wiki.php.net/rfc/pipe-operator-v3) - [Clone RFC](https://wiki.php.net/rfc/clone_with_v2) - [Single-expression functions in Kotlin](https://kotlinlang.org/docs/functions.html#single-expression-functions) ## Rejected Features Keep this updated with features that were discussed on the mail lists.