Re: [RFC] Strict Namespace Resolution

Hi Rowan, > On Jul 15, 2026, at 17:23, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > On 15 July 2026 19:17:43 BST, "Paul M. Jones" <pmjones@pmjones.io> 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. A reasonable stand, and thanks for the historical context. > 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 To be clear, it is driven neither by "offering choice" nor by "removing the fallback entirely". It is driven by offering a way to mitigate the shadow-global case in the Function Autoloading RFC. As it turns out, that case is relatively rare, but Tim opined this feature should be separate from Function Autoloading, so here we are. * * * Having said all of that, I am good with *some* form of a directive that helps with the rare but not non-existent shadow-global case. As this RFC stands now, is the directive name alone the main blocker for you, or is it also the values? Thank you for your patient attention. -- pmj