On 03/05/2022 12:37, Craig Francis wrote:

But what is that benefit? I'm sorry, but I really don't see it.


I started drafting a longer reply, but honestly I don't think we're getting anywhere. Every attempt to explain the benefit seems to end in one of two ways:

- an endless back and forth nit-picking hypothetical situations where it might or might not be useful - an outright dismissal that "people who want it strict can go over there and use strict_types=1 and/or static analysis"

To me, it's *always* about trade-offs: the *benefit* of strict checks exists for everyone, and the question is whether they want to pay the *cost* or not. As long as we can't agree on that fundamental point, there's no point continuing the discussion.


I'm going on the basis that you're ok with numbers in strings being coerced to integers/floats (which I also see as being useful, because you're right, most inputs are strings)... but you're not ok with NULL being coerced (which is also common, because values aren't guaranteed to be provided by the user, and NULL is typically the default).


I will reply to this point, though, because I think it's a genuinely interesting thing to ponder.

One significant difference is that not only is it often not *useful* to distinguish an input of 123 from '123', it's often not *possible*. There is literally no way for an HTTP URL or header to contain an integer, rather than a string representation of one, because it's not a binary protocol.

On the other hand, you might well receive an empty string as input where you're expecting an integer. Notably, that is *not* coerced automatically to zero; the code has to explicitly decide if that should trigger distinct behaviour (such as a validation error) or be treated as a default value. Not receiving a field you expected feels very similar, so similar behaviour feels reasonable.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to