The `strict_types` directive is limited to applying strict type checking, throwing a TypeError instead of doing implicit type casting.
The strict operators RFC is trying to do the same. Unfortunately there are a view of cases where this isn't easily possible and the statement will have a different result based on the flag. After a fierce discussion, the general consensus is that this should be minimized as much as possible (if at all). With bc-breaking changes, there has always had a similar notion. The old code should have the same effect or throw an error. Exceptions to this exist, but are rare. The P++ and edition proposals go completely against this premise. --- Secondly, introducing such a dialect would ultimately break up the language and stagnate the progression of PHP in general. For instance, I'd fear that something like the deprecation of the left-associative ternary operator would not make it into PHP 8, but instead would be forced towards the P++ dialect. Even though this has nothing to do with loose vs strict types. --- We should look and discuss to find alternatives that allow PHP to progress, but where bc-breaking changes result in an error (as much as possible) and do not (radically) change the behavior of PHP. [Arnold Daniels - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=4202n) [4202n] On August 11, 2019 at 10:36 GMT, Zeev Suraski <z...@php.net> wrote:
