php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #80552 Match is a reserved word
Submitted: 2020-12-25 15:57 UTC Modified: 2020-12-25 21:16 UTC
From: rasmus at mindplay dot dk Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 8.0.0 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: rasmus at mindplay dot dk
New email:
PHP Version: OS:

 

 [2020-12-25 15:57 UTC] rasmus at mindplay dot dk
Description:
------------
PHP 8.0 breaks any existing code with a class named "match", which became a reserved word for some reason.

PHP 7.0 intentionally loosened such reserved word restrictions, per the original release announcement here:

https://www.php.net/manual/en/migration70.other-changes.php

It would be nice if PHP continued in that vein to avoid more variations of this problem.

Parser failure is demonstrated with a minimal repro here:

https://3v4l.org/A9Glt

A quick google search reveals at least two major projects (PHPUnit and MediaWiki) affected by this change - here's a handful of examples from a quick google search:

- https://github.com/sebastianbergmann/phpunit/issues/4373
- https://github.com/wikimedia/mediawiki-vendor/blob/master/ruflin/elastica/lib/Elastica/Query/Match.php
- https://github.com/mindplay-dk/timber/blob/master/src/Match.php
- https://github.com/zweifisch/php-pattern-matching/blob/master/match.php
- https://github.com/extesy/foosball/blob/master/match.php


Test script:
---------------
<?php

class Match {}

class Matcher
{
    public function match(): Match {}
}

$matcher = new Matcher();

$match = $matcher->match();


Expected result:
----------------
It would be nice if this could be treated as a bug, and could be fixed with a minor release, such that packages that were broken by this change can be versioned correctly against e.g. PHP ^8.0.1, before everyone goes and starts renaming classes and functions.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-12-25 16:01 UTC] daverandom@php.net
This was explicitly accepted as part of an RFC and is therefore unlikely to be reversed: https://wiki.php.net/rfc/match_expression_v2#backward_incompatible_changes
 [2020-12-25 16:10 UTC] ilutov@php.net
> Globally reserved words as property, constant, and method names within classes, interfaces, and traits are now allowed. This reduces the surface of BC breaks when new keywords are introduced and avoids naming restrictions on APIs.

All of these already apply for match:
https://3v4l.org/QLIOW

All other keywords also still are not allowed in class names or namespaces:
https://3v4l.org/0Mbkh
 [2020-12-25 21:16 UTC] girgias@php.net
-Status: Open +Status: Not a bug -Operating System: Linux +Operating System:
 [2020-12-25 21:16 UTC] girgias@php.net
As already indicated by prior comments, this is not a bug as it's expected and was explicitly accepted with the RFC vote.
 [2020-12-26 10:10 UTC] rasmus at mindplay dot dk
Please consider this a feature request then.

There's no practical reason a parser needs to care which name comes after the class or function keyword, as long as it's a name - so this kind of error is just weird and distracting, and forces people into making breaking changes in libraries for no practical reason.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 16:01:28 2024 UTC