Hi Ilija, > This is because we don't generate a jumptable when there are less than > 5 integer conditions. Because of this inconsistency I'm not sure if we > should just remove the warning. As you mentioned, it could be > intentional in some cases. Tyson also mentioned that some constants > are platform dependent which would make it warn on some platforms but > not on others.
It's also inconsistent in that the float, false, null, true, and possibly arrays not containing objects or references don't have warnings. I'd prefer to go with leaving that check for linters or static analyzers, rather than an E_COMPILE_WARNING, because php compiles at runtime (unless preload is used properly) Multiple static analyzers can do this for switch, e.g. `phan --plugin DuplicateArrayKeyPlugin` https://github.com/phan/phan/tree/master/.phan/plugins#duplicatearraykeypluginphp If we did start doing this, I'd personally want it both for switch and match at the same time to be consistent, as a separate RFC. Another idea I'd thought of would be to add an `opcache.pedantic` mode for checks like that, which would warn about errors noticed by opcache (emitted at compile time, not runtime) within a single file without running the code (e.g. calling a function with the wrong type (strlen($obj), too few or too many arguments to native functions, dead code (e.g. conditions that were always true/false on a platform), etc). - Due to platform dependence, that would have false positives, which is why this would be called pedantic - This would emit errors directly to a log file or stderr, in order to not trigger side effects such as user error handlers - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
