Hello Internals,
I recently found out (after 15 years of being a PHP developer) that PHP allows using a semicolon rather than a colon after case statements. 1 I.e.:
switch ($value) {
case 'foo';
case 'bar':
case 'baz';
echo 'foo, bar, or baz';
break;
default;
echo 'Other';
}
Apparently this syntax has been allowed since at least the PHP 4 days, but very few developers know about it.
I ran a script on the top 1000 Composer packages to gauge usage, and out of 35,777 total case statements, only 15 in two packages used the alternate syntax. All were accidental typos (randomly mixed in with statements using the normal syntax), and I opened pull requests to fix both (the first has already been merged):
Would it be worthwhile for me to write an RFC to propose deprecating the alternate switch case syntax in PHP 8.5?
The main reason for deprecation/removal it is that it causes confusion. A developer may think the alternate syntax behaves differently in some way from a regular case statement (e.g. preventing fallthrough or something), when it actually does not.
Best regards,
Theodore
Note: The normal case syntax has been part of the PSR-2 coding style since 2012, and PHP-CS-Fixer automatically fixes usages of the non-standard syntax when using the @PSR2 or newer @PER-CS rulesets.
Hi Theodore,
Do you know why the two exist? Was there any historical reason for this?
From what cmb69 said1, it seems like it may exist because of the
implicit semicolon in ?>, and after I tested it, it seems to be true.
Was there ever any other reason?
Do you know why the two exist? Was there any historical reason for this?
From what cmb69 said1, it seems like it may exist because of the
implicit semicolon in ?>, and after I tested it, it seems to be true.
Was there ever any other reason?
Hi Kamil,
I hope no one writes code like that where separate <?php ?> tags are interleaved around each switch, case, break, and endswitch statement. That's atrocious...
Per the previous discussion that Claude linked to, the alternate syntax is a leftover from PHP/FI 2, where nearly all lines including if conditions and case statements were terminated by a semicolon. 2
Do you know why the two exist? Was there any historical reason for this?
From what cmb69 said[1], it seems like it may exist because of the
implicit semicolon in ?>, and after I tested it, it seems to be true.
Was there ever any other reason?I hope no one writes code like that where separate <?php ?> tags are interleaved around each switch, case, break, and endswitch statement. That's atrocious...
All my PHP based templates for the xdebug.org site use this style. I don't think it's atrocious, and quite a bit nicer than the "new" syntax.
It's also not a decades old choice (and not even by me).
cheers
Derick
Do you know why the two exist? Was there any historical reason for this?
From what cmb69 said[1], it seems like it may exist because of the
implicit semicolon in ?>, and after I tested it, it seems to be true.
Was there ever any other reason?I hope no one writes code like that where separate <?php ?> tags are interleaved around each switch, case, break, and endswitch statement. That's atrocious...
All my PHP based templates for the xdebug.org site use this style. I don't think it's atrocious, and quite a bit nicer than the "new" syntax.
It's also not a decades old choice (and not even by me).
Hi Derick,
I suppose whether or not that approach is ugly is somewhat subjective. Do the xdebug.org templates using this style also rely on case statements being followed by a semicolon instead of a colon?
Sincerely,
Theodore
Do you know why the two exist? Was there any historical reason for this?
From what cmb69 said[1], it seems like it may exist because of the
implicit semicolon in ?>, and after I tested it, it seems to be true.
Was there ever any other reason?I hope no one writes code like that where separate <?php ?> tags are interleaved around each switch, case, break, and endswitch statement. That's atrocious...
All my PHP based templates for the xdebug.org site use this style. I don't think it's atrocious, and quite a bit nicer than the "new" syntax.
It's also not a decades old choice (and not even by me).
Hi Derick,
I suppose whether or not that approach is ugly is somewhat subjective. Do the xdebug.org templates using this style also rely on case statements being followed by a semicolon instead of a colon?
Sincerely,
Theodore
Even if it did, it's not really relevant for the discussion.
I was mentioning this because removing the syntax would break code for no real gain.
Cheers
Derick
Hi
Am 2024-11-20 20:03, schrieb Derick Rethans:
All my PHP based templates for the xdebug.org site use this style. I
don't think it's atrocious, and quite a bit nicer than the "new"
syntax.
This proposal would not affect that. You would just need to add a colon
after the case statement, not a semicolon. In fact that would more
closely match the corresponding switch, which would also need to have
a colon:
<?php $foo = "bar"; ?>
<?php
switch ($foo):
case "bar":
?>
BAR
<?php break; case "baz": ?>
BAZ
<?php endswitch; ?>
Though using switch in such templates is somewhat finicky anyway,
because it will need to be merged with the first case, because
otherwise:
Parse error: syntax error, unexpected
T_INLINE_HTML"", expecting
"endswitch" or "case" or "default"
Best regards
Tim Düsterhus
This proposal would not affect that. You would just need to add a colon
after thecasestatement, not a semicolon. In fact that would more
closely match the correspondingswitch, which would also need to have
a colon:<?php $foo = "bar"; ?>
<?php
switch ($foo):
case "bar":
?>
BAR
<?php break; case "baz": ?>
BAZ
<?php endswitch; ?>Though using
switchin such templates is somewhat finicky anyway,
because it will need to be merged with the firstcase, because otherwise:Parse error: syntax error, unexpected
T_INLINE_HTML"", expecting
"endswitch" or "case" or "default"
There is no parse error if you use PHP snippets in such templates like
you use C preprocessor directives (i.e. always starting at the first
column); e.g. https://3v4l.org/cK0Ll. Or see https://3v4l.org/7mKS8,
which is how I would write it, if I was using switch statements in such
templates.
Note that I'm not advocating to keep the behavior, but I also don't see
how it would be harmful. Without an enforced CS, there can be more
confusing code anyway.
Christoph
Le 20 nov. 2024 à 15:45, Theodore Brown theodorejb@outlook.com a écrit :
Hello Internals,
I recently found out (after 15 years of being a PHP developer) that PHP allows using a semicolon rather than a colon after case statements. [1] I.e.:
Hi,
For reference, previous discussion on the subject:
https://externals.io/message/109350
—Claude
Le 20 nov. 2024 à 15:45, Theodore Brown theodorejb@outlook.com a écrit :
Hello Internals,
I recently found out (after 15 years of being a PHP developer) that PHP allows using a semicolon rather than a colon after case statements. [1] I.e.:
Hi,
For reference, previous discussion on the subject:
https://externals.io/message/109350
—Claude
Interesting history! Chesterton's Fence gate achieved. :-)
Unless it's causing parser issues somewhere I don't think we need to address it. Maybe just document that one really shouldn't use it, and it's only there for legacy reasons. That said, if someone wants to go to the work of removing it, I'd probably support it.
--Larry Garfield
Unless it's causing parser issues somewhere I don't think we need to address it. Maybe just document that one really shouldn't use it, and it's only there for legacy reasons. That said, if someone wants to go to the work of removing it, I'd probably support it.
I don't feel particularly strongly about it, but I am inclined to write an RFC to deprecate it, since removing some of these little-known legacy syntaxes makes the language cleaner and less confusing, and sometimes can even pave the way for future features.
For example, the curly brace syntax for accessing array elements and string offsets was deprecated in PHP 7.4,1 and if I recall this made possible the property hooks syntax we have now in PHP 8.4.
Sincerely,
Theodore
Hi
Am 2024-11-20 19:45, schrieb Theodore Brown:
I don't feel particularly strongly about it, but I am inclined to write
an RFC to deprecate it
It doesn't feel big enough to warrant its own RFC, but I would be happy
to see it as part of https://wiki.php.net/rfc/deprecations_php_8_5.
Best regards
Tim Düsterhus
Am 2024-11-20 19:45, schrieb Theodore Brown:
I don't feel particularly strongly about it, but I am inclined to write an RFC to deprecate it
It doesn't feel big enough to warrant its own RFC,
but I would be happy to see it as part of https://wiki.php.net/rfc/deprecations_php_8_5.Best regards
Tim Düsterhus
Hi Tim,
I have now added an item to the general deprecations RFC for PHP 8.5 to deprecate terminating case statements with a semicolon.
Kind regards,
Theodore Brown
Hello Internals,
I recently found out (after 15 years of being a PHP developer) that PHP allows using a semicolon rather than a colon after case statements. 1 I.e.:
switch ($value) { case 'foo'; case 'bar': case 'baz'; echo 'foo, bar, or baz'; break; default; echo 'Other'; }Apparently this syntax has been allowed since at least the PHP 4 days, but very few developers know about it.
I ran a script on the top 1000 Composer packages to gauge usage, and out of 35,777 total case statements, only 15 in two packages used the alternate syntax. All were accidental typos (randomly mixed in with statements using the normal syntax), and I opened pull requests to fix both (the first has already been merged):
Would it be worthwhile for me to write an RFC to propose deprecating the alternate switch case syntax in PHP 8.5?
The main reason for deprecation/removal it is that it causes confusion. A developer may think the alternate syntax behaves differently in some way from a regular case statement (e.g. preventing fallthrough or something), when it actually does not.
Best regards,
TheodoreNote: The normal case syntax has been part of the PSR-2 coding style since 2012, and PHP-CS-Fixer automatically fixes usages of the non-standard syntax when using the @PSR2 or newer @PER-CS rulesets.
Hi
I'm not convinced that getting rid of this is a good idea.
It doesn't seem to cause real harm and as Kamil/cmb pointed out there was a legit reason to have this.
So I'm not in favor of deprecating this.
Kind regards
Niels