> > 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'. > > > > > No, it's saying that whatever name you use, the guarantees of behaviour are > only as strong or weak as decisions we make in the future about Backwards > Compatibility. That's no more or less true for one mode than the other, > regardless of what we call them. > > > Any changes I don't expect to strict_types or function_and_const_lookup > > would be discussed in the RFCs proposing those changes. > > > > Yes, and that includes changes to how 'fallback' mode works.
I've decided against proposing 'fallback', so I'm not planning to work out how a future 'fallback' would work. I don't have anything to add for what I want 'global' to mean. > 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. > OK, bad example; what if we make the rules around int->float coercion stricter? The point is, why is a breaking change to mode 1 fundamentally different from a breaking change to mode 0? If 'fallback' and 'default' ever mean different things, > we'll very likely need to add 'default' again if namespace-scoped declares > become a thing. > > I still don't understand why you would ever want that. Perhaps it would > help to think about specific examples: If a future language change changed the *default* resolution rules for functions or constants, I'd rather have future maintainers make the decision on whether to add a 'fallback' to make migration than on whether to remove the 'fallback' if it didn't make sense to support it. We have different values and expectations on what's likely to happen in the future of the language. > Can you provide an example of when you'd want to use 'default' instead of > specifying the mode you've written the file to run in? > > > 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. > > Sure, and I gave a rule of thumb for that earlier: "default" makes sense > when the setting *doesn't actually matter*, and you want to delegate the > decision. That doesn't seem to apply to this case. The use cases are similar to the reasons why I'd want to use strict_types=0. strict_types=0 is rare in practice. 1. Explicitly writing in code that you have chosen on a setting for the file and decided not to use 'global'. 2. Overriding the namespace default if https://wiki.php.net/rfc/namespace_scoped_declares gets accepted. That rule of thumb isn't the possible reason for why someone would use the name "default". - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
