On Tue, 28 Jan 2020 at 18:13, tyson andre <tysonandre...@hotmail.com> wrote:
> 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. > 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: When I write file foo.php, I know that I want to use functions in the current namespace if they are defined. So I add declare(function_and_const_lookup='fallback') to that file to make sure it continues to work: * If the PHP default changes to 'global', the file setting will tell it to use 'fallback' mode instead * If a namespace-scoped declare is set to 'global', the file setting will take precedence, so it will still use 'fallback' mode Similarly, when I write file bar.php, I add declare(function_and_const_lookup='global'); no matter what the PHP default or namespace-scoped setting say, the file will act as I intended. 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? > A 'fallback' can be added if and when we have a use case for it. > I'm saying we do have a use case: enabling forwards compatibility so that we can change the default in future if we want to. I'm still trying to understand the use case for 'default', though. > 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. Regards, -- Rowan Tommins [IMSoP]
