On 15 July 2026 19:17:43 BST, "Paul M. Jones" <[email protected]> wrote:
>I can see why some might think that; even so, it is still a valuable addition >(however small) even if the old behavior is never removed, in the same way >that strict_types is valuable even though the old behavior has not been >removed. I'm going to bang this drum again: neither mode of strict_types is older than the other. Both were designed at the same time, when scalar type declarations were added to the language, and the directive was to let users choose between two competing designs. In hindsight, both the name of the directive, and the details of "mode 0", really needed more polish. Unfortunately, by then everyone was exhausted by several thousand emails arguing about the topic, and relieved that any sort of consensus had been reached. That's why I'm so keen *not* to base the name and options of this feature (or any other) on the strict_types precedent. If this is truly about offering choice, name it clearly as such, and offer all three modes (global-only, current-ns-only, fallback). If the purpose is to somehow move towards removing the fallback completely, then we should explicitly work towards that goal, e.g.: - name the directive to imply future vs past, e.g. legacy_name_fallback - in 8.next, emit a deprecation in certain situations if neither legacy_name_fallback=1 or legacy_name_fallback=0 is set - in 9.0, that could become an error, but both modes still available - in 10.0, legacy_name_fallback=1 would become an error, and legacy_name_fallback=0 would be a no-op as it would be the default behaviour Or, as proposed several years ago, just deprecate the behaviour directly and pick a new behaviour for all code as of PHP 9.0. People will complain about finding their backslash keys, but they'll get used to it. Regards, Rowan Tommins [IMSoP]
