On Fri, Jan 28, 2022 at 3:13 PM Robert Landers <landers.rob...@gmail.com>
wrote:
> I would posit differently. In my experience in upgrading code, it was
> mostly intentional.
> Here's an example:
>
> ----
> if($doThing) {
> $doOtherThing = maybe();
> }
> // later
> if($doOtherThing) {
> doOtherThing();
> }
> ---
>
> There's no bug here, nothing is unintentional, and the intent is clear.
> Now,
> if we want to get rid of the warning we need to say $doOtherThing = false
> before getting to the first if-statement, but should this halt everything
> in
> production? I don't personally think so and it would be undesirable for it
> to do so.
>
Let me go over this.
> There's no bug here, nothing is unintentional, and the intent is clear
I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell whether or
not this code is suffering from a merge conflict, and I cannot guarantee
that whatever type `maybe();` returns here works. If at some point the
return type of `null` is changed to `false`, while the assumption of
undefined is `null`, passing `false` to a nullable typed argument later on
will break.
> Now, if we want to get rid of the warning we need to say $doOtherThing =
false before getting to the first if-statement
Thank you for pointing to the example above. `null` and `false` are
different values. Your assumption here is that setting it to `false` would
fix the problem, but the actual value would've been `null` and changing it
to `false` might actually break more.
> but should this halt everything in production? I don't personally think
so and it would be undesirable for it to do so.
Any type error should if you ask me. Unexpected types cause unexpected
behavior, and the longer PHP will try to continue with assumptions of types
and implicit casting, the bigger the damage can be. All this type juggling
is headache material and the less I see of it, the better.
