Bug #75138 [Nab]: Nested "IF" triggers Exception when it is before "else:" or "elseif:".

Edit report at https://bugs.php.net/bug.php?id=75138&edit=1 ID: 75138 Updated by: requinix@php.net Reported by: jcmarchi at gmail dot com Summary: Nested "IF" triggers Exception when it is before "else:" or "elseif:". Status: Not a bug Type: Bug Package: *Programming Data Structures Operating System: All PHP Version: Irrelevant Block user comment: N Private report: N New Comment: If you want a fifth opinion, I agree with peehaa, nikic, rhsoft, and yohgaki: this isn't a bug. The second semicolon you're making a fit about changes the meaning of the structure. It introduces another statement (even if empty) and breaks the if/else pair apart, thus avoiding the dangling else problem. https://3v4l.org/0vsMV It's not a workaround. It's syntax. Previous Comments: ------------------------------------------------------------------------ [2017-08-31 14:20:35] jcmarchi at gmail dot com @peehaa, you should re-open this BUG report because IT IS a bug! Or, at least, have the decency to gather a second opinion about it. You came to a conclusion too quickly and based on a sole visual analysis of the code samples (I bet you didn't even try some scenarios, did you?), and also by misinterpreting the PHP manual guidance... :S If a double semicolon ";;" or a semicolon after the closing curly bracket "};" requirement to fix a code parsing problem is not considered a bug, then I don't know what will ever be. By keeping this BUG REPORT open, other PHP developers (more willing to really make PHP better), will have a chance to look into it and come up with a real solution. Thank you. ------------------------------------------------------------------------ [2017-08-30 23:56:33] jcmarchi at gmail dot com @spam2, YES, I read it. More than that, I analyzed what is said there, I read more about "scannerless parsing" (not the case because it doesn't apply to PHP, which is bytecode by Zend Engine) and other processes discussed there, and I understood the whole discussion around the "dangling else" condition for the languages that are affected by it (PHP is not one of them). As much as it would be easy to simply accept that, read my answer to @yohgaki. He brought material to research and added good points to the discussion, but sadly it didn't explain what I replied to him, neither excused PHP from behaving the way it behaves for in the proposed conditions. You should really try some code samples. Create your own! Target the ";;" and "};" specific examples as reference. Remove these elements, redesign the logic without "unnesting" the problematic code. Prove me wrong about the bug or explain how ";;" and "};" fixes the issue even when it is not part of PHP concept and remember: "blank lines" should not affect the logic in place. Then this discussion may get to a valuable conclusion or an acceptance of the BUG existence. :) ------------------------------------------------------------------------ [2017-08-30 23:36:20] jcmarchi at gmail dot com @yohgaki, thank you for providing valuable insight to the (so far) useless discussion! The parsing issue in the PHP case can be easily observed in the "double semicolon" example. The question is: why, when adding an extra semicolon before the "else:" or "elseif:" magically resolves the "nested IF" problem? After all, in PHP, blank lines should not affect the logic, right? Well, in this case, IT DOES! It is not exactly ambiguity problem as no more than one correct parse tree actually exist (only in the eye of the blind ones). If an "IF" statement nested block begins with ":" and ends when an "else:" or "elseif:" is found, the "nested IFs" should all work or fail equivalently, but just the last "IF" fails (and it doesn't have a ":" to create ambiguity). It is crazy to see people who should be going to the PHP Source Code and look for answers (or solutions), or even bring something factual to the table, discussing the quality of "code samples". The only things that matter in those samples are the ";;" and "};", which fixes the "nested IF" issue, and AFAIK such approach is not even part of the PHP coding principle. It is depressing, if not tragic! ------------------------------------------------------------------------ [2017-08-30 23:19:01] spam2 at rhsoft dot net no, i didn't play with the samples on my smartphone BUT DID YOU read the link about "dangling else"? ------------------------------------------------------------------------ [2017-08-30 23:15:36] jcmarchi at gmail dot com If you are trying to (childishly) offend me, well... Sorry to disappoint you. Why? Because I agree with you! Some "freedoms" while coding should be chopped out. However, while language allows it, it should be (at least) bug-free. What is unbelievable, however, is people that keep focusing on the "wrong wrongs" simply to ignore the problem at hand. Those are the ones I DO fire (the ones that go to the extreme of self-blindness simply to avoid accepting they are wrong). I bet you didn't even play with the code examples... Or even created your own... Did you? /me -- All hopes for the technology world are lost, forever! ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75138 -- Edit this bug report at https://bugs.php.net/bug.php?id=75138&edit=1