php-fig
Forbid use of semi-colon on switch case/default statements
These are almost never used, and are now deprecated in PHP 8.5. Let's go ahead and tell people to never use them in any version.
switch ($val) {
case 1; // This works until 8.5, who knew? But we shouldn't allow it.
print $val;
case 2: // This is the correct way.
print $val * 2;
}
Is it the place of a coding standard to forbid using a deprecated syntax ?
In my opinion, this is not a code style issue, but a language issue and PHP will warn when people use this syntax on PHP versions which don't support it.
If anything, a blanket rule "don't use features which are deprecated for your target PHP version" might as well be added, but historically, the FIG CS standards were only published/approved if they could be automatically enforced and a blanket rule like that will never be fully enforceable via automated tooling.
As a side-note: if you want to forbid the semi-colon as a statement closer for case/default, will you also forbid moving in and out of PHP within a switch ?
switch ($val) {
case 1 ?><!-- Yes, this will also trigger the deprecation notice as PHP inserts a semi-colon before the PHP close tag. -->
<div><?= $val ?></div>
<?php break ?>
<?php case 2 ?>
<div><?= $val * 2 ?></div>
<?php break;
}
The coding standards have long said not to use certain rarely-used or problematic syntaxes. Eg, they require <?php and not <?, and disallow var, even though neither of those are technically deprecated. I agree that it's not something we should do lightly, but in this case, the RFC discussion showed that most people didn't even know a semicolon was allowed in the first place. The impact should be minuscule.
The question of semi-colons in a in/out switch statement like that... seems more like an issue for internals, since they may not have realized that would be impacted. Though again, I think the likely answer will be something like "why in the world would you do that?"
The question of semi-colons in a in/out switch statement like that... seems more like an issue for internals, since they may not have realized that would be impacted.
This is known (or should be considered as such) and was mentioned in either the internals discussion or the PR thread by one of the PHP Core devs. I saw the mention when I started writing the PHPCompatibility sniff for this deprecation, which is why I dug in deeper and investigated.
The coding standards have long said not to use certain rarely-used or problematic syntaxes.
"rarely-used" and "problematic" are highly subjective terms in this case, as they depend 100% on the environment someone works in. There's bound to be a company somewhere in the world using semicolons as the default for case/default statement and now being highly annoyed at the PHP 8.5 deprecation and having to re-educate their devs 🤷🏻♀️
I agree that it's not something we should do lightly, but in this case, the RFC discussion showed that most people didn't even know a semicolon was allowed in the first place. The impact should be minuscule.
Which is exactly why I believe it is a bit silly to do it for this deprecation (rarely used, most people don't even know).
Side note: AFAICS, PHPCS has enforced this being a colon, not a semi-colon, via the PSR2 sniff since 2012 (before my time). I know Greg was always very strict about what is checked in the PSR sniffs, so this is bound to have been discussed on the FIG mailinglist or something... ? Or maybe it was semi-accidental and the intention was only to forbid : {...} ? 🤷🏻♀️
I don't think it's necessary to explicitly mention this deprecated syntax in the standard. The code example for switch already shows the correct usage and is enforced by PSR/PER CS fixers.
A note about not using a semicolon would have to be removed when PHP 9 comes out and the semicolon becomes a syntax error.
