PHP RFCs I am excited about

PHP has come a long way from its humble beginning as a template language. Nowadays, we can create sophisticated web applications following best practices such as SOLID. PHP has been improving rapidly in the last five years, and it does not seem like its stopping any time soon.

PHP uses RFCs, short for Request for comments, to discuss and finalize on new features. Below are some of the RFCs I am excited about.

non-capturing catches [ Official Link ]

This RFC proposes that PHP enable us to omit variables in our catch clause. This Will allow us to handle situations where we only care about the type of exception and not its data. The unused variable in catch clause can cause confusion about if the variable being unused is a bug or intentional.

try {
  //some code
}
- catch(SomeException $x)
+ catch(SomeException) {
 //rollback or something
}

If you too like this then you are in for a treat, because the voting for this stands at 45(Yes)-1(No). So, it will likely be included in PHP 8.

Constructor Property Promotion [ Official Link ]

This provides syntactic sugar when creating classes. Basically, it reduces boilerplate code.

Consider the following code snippet

class Point 
{
    public float $x;
    public float $y;
    public function __construct(float $x,float $y) {
        $this->x = $x;
        $this->y = $y;
    }
}

As you can see, the properties are repeated three times (instance property declaration, constructor parameter declaration, assignment).
With this RFC, we can reduce it to

class Point {
    public function __construct(public float $x,public float $y) { }
}

Under to hood, PHP desugars the above to our first example. But, it makes our job easier and the code much cleaner and concise.

The voting stands at 37(Yes)-9(No)

Conditional return, break, and continue Statements [ Official Link ]

This RFC proposes a syntactic sugar that makes return/break/continue on a specific condition clean.

Proposed syntax 1

function something() {
    return if (someCondition): true;
    return if (someCondition); // Returns void
}

Proposed syntax 2

function something() {
    return true if (someCondition);
    return if(someCondition);
}

Personally I like the first syntax as it is easier to identify that we are reading conditional return (if directly follows return), while in the second syntax if the return value is longer, the if may be far from return.

return $this->someObject->callSomeMethodWithAVeryLongNameThatIJustMadeUpToProveAPoint() if (someCondition); // Contrived example

As you can see, the return and if are very far from each other. This increases the cognitive load while reading code and a programmer may even miss the condition if the if (😉) is off the screen.
This RFC is still under discussion.

Deprecated attribute [ Official Link ]

As our codebase matures, certain parts of it become obsolete or we have a better implementation. Currently, we can use the @deprecated doc block tag to specify deprecated methods. With this RFC, this feature is integrated into the language, and calls to such methods will trigger deprecation notice. This RFC will help in cleaning our APIs easily.
This RFC, too, is still under discussion.

Named Arguments [ Official Link ]

This RFC aims to make a function call easier and self-documenting. Normally when calling a function, we need to pass the parameters in the same order that they were declared. However, this RFC enables us to call a function by passing parameters in any order using its name.

$person->update(
    name: $newName,
    age: $newAge,
    isManager: true
);

This simplifies method calling and also makes the code self-documenting. Consider that we were calling the above method using the current code.

$person->update(
    $newName,
    $newAge,
    true // What does this mean? What is true?
);

In the first snippet, we know we are setting isManager to true, but in the second snippet, we have no idea what true means.

This also helps us to avoid bugs caused by the wrong ordering of parameters while calling a method. Consider, the following snippet

class Product {
  // Other code
  public function updateRates(float $salesRate, float $purchaseRate) {
    //Method body
  }
}

// Calling code
$product->update($purchaseRate, $salesRate);

Astute readers may already have found the bug in the above snippet. We are using purchase rate in place of sales rate and vice versa. The compiler won't be of any help here either as the types of both parameters match. This bug would not have occurred with named arguments

$product->update(purchaseRate: $purchaseRate, salesRate: $salesRate);

This RFC is under discussion.

ENUM [ Official Link ]

Currently, we use multiple constants in our programs without any linking between them. However, most of the constants are logically related, but there is no way to represent this using PHP, other languages use Enums to solve this problem. This RFC proposes similar behavior in PHP.

// Old
const STATUS_PENDING = 1;
const STATUS_APPROVED = 2;
const STATUS_SHIPPING = 3;
const STATUS_DELIVERED = 4;

// new
enum Status {
    Pending = 1, // Default is zero. Using 1 here will use 2 in the next
    Approved,
    Shipping,
    Delivered
}

As you can see, in the second example the constants are logically linked while in the first one, it's not that clear (aside from naming).

Another benefit is that we can use the enum as a parameter type to methods too.

public function updateStatus(Status $status) {
    // Perform business related logic 
    $this->status = $status;
}
....
$shipment->updateStatus(Status::Shipping);

This RFC is still under discussion.

Closing Thoughts

It's an exciting time for PHP with many changes and improvements (in speed, developer experience) being introduced and discussed. Let's see how one of the oldest web programming language evolves in this fast-changing web development landscape.

So, what interests you the most amount the above RFCs or any other open RFCs in PHP? Share your thoughts below