On Tue, 28 Jan 2020 at 15:42, tyson andre <tysonandre...@hotmail.com> wrote:
> > In other words, we don't need to know what the future modes are to know > what modes we have *right now*, and give those modes names. > > If strict_types had a name instead of a number, we'd have a similar > argument > over whether there should be a `strict_types='off'` vs `='default'` > and `strict_types='on'` > I have always read 0 and 1 as meaning 'off' and 'on' in that context; the idea that 0 could mean "whatever the current PHP default is" is completely new to me. (I actually find it slightly unidiomatic for PHP to use a number rather than a string there.) > - Confusion by new developers over whether `'fallback'` is weaker than > omitting the option. > What do you mean by "weaker"? A value of "fallback" would mean "I expect function calls in this file to refer to the same namespace if possible, and fall back to the global namespace"; no more, and no less. That feels like a well-defined and useful assertion. A value of "default" would presumably mean "I have no expectations about what function calls in this file should refer to, and am happy for PHP to arbitrarily change their meaning in future in undefined ways". Why would anyone want to assert that? > (e.g. if `count()` uses a keyword that's always the global function, > like `empty()` currently does, as an unrealistic/undesirable example) > ... > If php changes the default casting behavior to forbid weak casting boolean > to string > or string to boolean (as another unrealistic example), I personally > wouldn't expect strict_types=0 to be required to allow it. > Let's flip those examples around: what if we want to make some magic function always resolve to the current NS even in function_and_const_lookup='global' mode, or a particular cast be allowed even in strict_types=1 mode? The two different modes for strict_types aren't even "old" and "new", they were both added at the same time, so there's no reason one should have a stronger BC guarantee than the other. Calling the mode 'default' won't stop people's code breaking if we change the resolution rules, and won't mean we can just ignore breaking changes, any more than if we hadn't added the mode switch in the first place. All it means is that if we change the default *mode*, it's unnecessarily difficult for people to migrate (see previous example scenarios). My worst fear is that we add this mode labelled as 'default', but actually tie it to the current behaviour, so that we eventually have a mode called 'default' that isn't the default. This happened to Wikipedia: they named their default skin 'standard', then regretted it when they changed the default to be something else. Regards, -- Rowan Tommins [IMSoP]
