> What do you mean by "weaker"? Any difference that might be expected by a user when for what differs between leaving out the setting and setting it to 'fallback'/'default'.
E.g. in my example for `count`, a developer might expect `MyNs\count()` to continue working as `MyNs\count()` when they set the value to 'fallback', even when it became a keyword. > 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. That's more of an objection to 'global' than an argument about 'fallback' or 'default'. It isn't suggesting a name to use instead of 'global'. Any changes I don't expect to strict_types or function_and_const_lookup would be discussed in the RFCs proposing those changes. For allowing a particular cast with strict_types=1, only strict_types=1 would probably need to be changed to keep backwards compatibility, since code without TypeErrors would continue to work. > 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). Preventing future RFCs from breaking code in small or large ways (or mitigating it) I have no knowledge of is something I'd consider outside of the scope of this RFC. Those RFCs would have to plan for how users should be notified of and migrate code when there are breaking changes to the defaults, whether or not function_and_const_lookup was added in this form. If 'fallback' and 'default' ever mean different things, we'll very likely need to add 'default' again if namespace-scoped declares become a thing. So I'm adding 'default', and only 'default' for the RFC vote. > 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. I'm opposed to making 'default' become anything other than omitting the setting (from every place it could be set), and would want the fact that is intended to be the same as omitting it (for as long as possible) to be well documented. Of course, what you mention could still end up happening; I still consider that unlikely. A 'fallback' can be added if and when we have a use case for it. There are large numbers of settings with values of 'standard'/'default' that became problems. There are large numbers of settings with values of 'standard'/'default' that made perfect sense and didn't cause any issues. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
