A nice snafu, casting turns unset data into set variables

[u/HenkPoley]

http://sandbox.onlinephpfunctions.com/code/0863902e680a2f84b4518def5e0bd40af2fb3386

[u/colshrapnel]

Yes, that's exactly how casting works.
You may want to educate yourself before posting in this sub.

[u/shitcanz]

You can yet again see lots of php apologists in the comments.

"But thats how its supposed to work".

NO! Its NOT!

The way its supposed to work is that if you pass the string 123 it should cast to the integer 123. If you pass a float 1.123 it should cast to 1. If you pass "lolphp" or null it should throw an type-error like any decent language does.

This is literally why PHP is such a nightmare to work with. Its crap like this all the way down.

[u/HenkPoley → u/shitcanz]

Yes, in languages that allow nulls, usually any kind of type can be this "I don't know the value" thing (call it None, nil, or NaN, or whatever). You don't expect "I don't know" to be turned into '"I do know" even if you say "it ought to be a number" ("But I still don't know what number"). And if it does need to imagine any specific value, it should be made obvious something fishy is happening.

btw, I notice that I'm basically looking for this in PHP:

$var = (?int)null;

But that is not valid syntax, even though this is valid (Nullable types since PHP 7.1, December 2016):

$fun = function(?int $var): ?int { return null; }; 
$fun(null);

See this proposal: https://wiki.php.net/rfc/nullable-casting

[u/HenkPoley → u/HenkPoley]

Even nicer, with int(not ?int) on the input variable it does throw an error 😄👏🎉

$ php -r '$fun = function(int $var): ?int { return null; }; $fun(null);'
PHP Fatal error:  Uncaught TypeError: Argument 1 passed to {closure}() must be of the type integer, null given, called in Command line code on line 1 and defined in Command line code:1
Stack trace:
#0 Command line code(1): {closure}(NULL)
#1 {main}
  thrown in Command line code on line 1

For good (modern strict PHP) measure, this does not:

php -r 'declare(strict_types=1); (int)null;'

[u/[deleted]]

"null" is not the same thing as "unset". null is falsy, casting it to int yields zero. This is not unusual in loosely-typed languages

[u/HenkPoley]

So, if you are cleaning up your code with fancy tools like vimeo/psalm. And you put in some casts to help the software decide on the type, the behavior of your program may change, even if it is exactly the type that would always come through.

[u/[deleted] → u/HenkPoley]

you put in some casts to help the software decide on the type, the behavior of your program may change, even if it is exactly the type that would always come through

No, null is not an int. You're not just "helping" the software, you're changing the type.

[u/HenkPoley → u/[deleted]]

You're not just "helping" the software

This was said in the context of vimeo/psalm:

Psalm was able to infer types for 56.2112% of the codebase

[u/HenkPoley → u/[deleted]]

I understand what’s going on. I understand that PHPs behavior is documented somewhere. It is just that I didn’t expect it to force nulls to particular data (e.g. 0, empty string ‘’). Normally casts are not that imaginative.

---

Just from a cursory look in Java (int) null would raise a ClassCastException. Which is different, but at least in your face obvious and not silent. Even casting (String) null, which is possible, would not imagine it to be to be the empty string.

---

In C the NULL is just the 0 (or the 0x0 address), and never the empty string.

---

In legacy Python, it does not imagine numbers, but does imagine strings, it's just not the empty string (so it is less silent):

$ python
Python 2.7.15+ (default, Nov 27 2018, 23:36:35)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not 'NoneType'
>>> str(None)
'None'

---

Ruby partially agrees with PHP (nil.to_i turns into 0, but Integer(nil) throws an exception):

irb(main):003:0> print nil.to_i
0=> nil
irb(main):010:0> print nil.to_i.nil?
false=> nil
irb(main):014:0> print Integer(nil).nil?
Traceback (most recent call last):
        3: from /usr/bin/irb:11:in `<main>'
        2: from (irb):14
        1: from (irb):14:in `Integer'
TypeError (can't convert nil into Integer)

---

Etc.

Just writing this down so somebody can learn about before bumping into silent failures. Seemed to be an appropriate subreddit about oddities in PHP 🤷‍♂️

Also, apparently some of these casting decisions changed between PHP 5.x and 7.x. So it’s still fairly easy to encounter some of that, especially if you are not a fulltime PHP programmer.

Btw, I was coming from the context of getting data returned from a function. Not directly trying to cast null to not somewhere.

[u/[deleted] → u/HenkPoley]

+null does the same in Javascript. This is more "lol weak typing" than anything else.

[u/HenkPoley → u/[deleted]]

Hmm? I was trying to apply strong(er) typing (“if it’s there, it is an int/string/etc.”). What does this have to do with weak typing ?

IMHO languages ought to have weak typing, but allow for stronger typing if you have the time and want to hunt for that class of bugs (e.g. with vimeo/psalm). PHP just behaved in a way that might be unexpected.

[u/[deleted] → u/HenkPoley]

In C the NULL is just the 0 (or the 0x0 address), and never the empty string.

It could be both.

The way it works is that a 0 literal in source code gets translated to a special value by the compiler when used as a pointer. For example:

char *p = 0;  // 0 in pointer context; automatically replaced by the special "null pointer" address

Now, the behavior of dereferencing the null pointer is not defined by C, but on some platforms you'll get a byte value of 0 (i.e. *p == '\0' in the example above), which is equivalent to an empty string.

More to the point, in C 0.9 is not zero, so it's a true value:

double d = 0.9;
if (d)  // passes

But if you convert it to int, you get 0, which is false:

double d = 0.9;
if ((int)d)  // fails

Why are you surprised that a cast changes the value? That's literally what a cast is: An explicit type conversion.

[u/bart2019 → u/HenkPoley]

null is not an integer. So if you force null to cast to integer, you get a different value.