PHP RFC: Function Alias for class methods declaration

• Version: 1
• Date: 2025-07-24
• Author: Dmitrii Derepko, xepozzd@gmail.com
• Status: Draft (Later in the RFC process “Under Discussion”, “Voting”, and finally “Accepted”, “Declined” or “Implemented”)
• Implementation: https://github.com/...

Modern languages use short constructions to boost developer experience. PHP as a modern language should follow in steps as well and re-use best practices of the others. I would like to make the fn keyword available to declare class methods.

Modern languages, such as Kotlin, Rust, Python use short function declaration keywords such as fn, fun, def.

PHP uses function which is 4x longer that fn, which is already in use in other parts of the language, such as closures.

Make fn keyword fully aliased for class methods:

<?php
 
class A {
    fn main() { // "fn" instead "function"
        echo "main function";
    }
 
    fn __construct() { // constructor's function can be changed as well
        echo "__construct function";
    }
 
    function __destruct() { // classic "function" is still available
        echo "__destruct function";
    }
}
 
?>

This is fully equivalent to

<?php
 
class A {
    function __construct() {
        echo "__construct function";
    }
 
    function main() {
        echo "main function";
    }
 
    function __destruct() {
        echo "__destruct function";
    }
}
 
?>

Remember that the RFC contents should be easily reusable in the PHP Documentation. This means, if at all possible, they should be runnable as standalone, self-contained code with the proof-of-concept implementation.

Simple example:

<?php
 
class A {
    fn main() { // all methods are public by default
        echo "main function";
    }
 
    public fn main() {
        echo "main function";
    }
 
    protected fn main() {
        echo "main function";
    }
 
    private fn main() {
        echo "main function";
    }
 
    abstract fn main();
}
?>

Example showing an edge case:

<?php
 
echo "Edge case";
 
?>

- Breaks backward compatibility because of new syntax construction.

PHP 9.0

What effect will the RFC have on IDEs, Language Servers (LSPs), Static Analyzers, Auto-Formatters, Linters and commonly used userland PHP libraries?

Will existing extensions be affected?

Describe the impact to CLI, Development web server, embedded PHP etc.

Make sure there are no open issues when the vote starts!

- [RFC] Function Alias for function declaration

Modern languages provide developers simple ways to define most popular constructions, such as short constructors, short functions, omitting mindless keywords and etc.

This RFC make PHP a step closer to a modern PHP look:

<?php
 
class MyService(private AnotherService $service): AbstractService(prefix: 'my') {
    fn getApiVersion() => 1;
 
    fn doProxy() {
        return $this->service->main();
    }
}
 
?>

Instead, classic syntax is still available and much verbose:

<?php
 
class MyService extends AbstractService {
    function __construct(private AnotherService $service) {
        parent::__construct(prefix: 'my');
    }
 
    function getApiVersion() {
        return 1;
    }
 
    function doProxy() {
        return $this->service->main();
    }
}
 
?>

This examples uses short constructor RFC syntax, single expression function syntax and have function -> fn alias

Yes, it should, but with no deprecation warning. Modern codebase will use short syntax (on demand), old projects/libraries won't be re-writed, so classic “functions” should live longer.

Yes, in another RFC.

Yes, as you wish:

<?php
 
class A {
    fn get() {...}
    function set($value) {...}
}

As it's fully-alised it can be replaced vise-versa. The reason to use it so is up to you.

Pick a title that reflects the concrete choice people will vote on.

Please consult the php/policies repository for the current voting guidelines.

Links to proof of concept PR.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

After the RFC is implemented, this section should contain:

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

Links to external references, discussions, or RFCs.

Keep this updated with features that were discussed on the mail lists.

If there are major changes to the initial proposal, please include a short summary with a date or a link to the mailing list announcement here, as not everyone has access to the wikis' version history.