Bug #80552 [Com]: Match is a reserved word

Edit report at https://bugs.php.net/bug.php?id=80552&edit=1 ID: 80552 Comment by: rasmus at mindplay dot dk Reported by: rasmus at mindplay dot dk Summary: Match is a reserved word Status: Not a bug Type: Bug Package: *General Issues PHP Version: 8.0.0 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2020-12-25 21:16:07] 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-25 16:10:30] 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 16:01:41] 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 15:57:19] 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. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=80552&edit=1