All the discussion aside, there is so much wrong with it:
First of all, why does the function even accept strings? There should be some eception happening.
Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)
> First of all, why does the function even accept strings?
Why not?
> There should be some eception happening.
PHP's built-in functions do not ever throw exceptions.
> Second, why does it return 0, i could understand NULL but not 0
Well it doesn't anymore, but it used to, and that kind-of made sense in the context of the language being PHP: in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number:
> php -r 'print (1 + "3") . "\n";'
4
when the string can not be parsed to a number (meaning it is not prefixed by something which looks like a number), it's just converted to `0`:
> php -r 'print (1 + "whelp") . "\n";'
1
And I expect that is the former behavior of the function: it coerced whatever it got to a number, so an empty or non-numeric string would get converted to the float 0.0, which would then get formatted as usual.
I don't think you got to the real problem here. Weak types are quite useful for some tasks, and of course they are nothing new. Languages that convert between integer and string types automatically are well suited for text processing in general (including generating web pages dynamically).
The problem with PHP's weak typing is PHP's hit-and-miss implementation. Check out AWK, another weakly typed language, for example:
Not that I disagree, but PHP only got exceptions relatively recently. The built-in functions existed long before that. Without exceptions, the options for error handling are to return an error value or exit, writing an error message somewhere. Null seems like an appropriate error value for "you asked for some data formatted as a string, and for whatever reason, I couldn't provide it".
PHP is a dynamically typed language, so although it expects a number, it will accept a string as it will try and parse that string into a number (e.g. you could pass it the string "2.23232" and it will work in the same way as if you pass it 2.23232 as a float). In this particular case, as the empty string can't be parsed into a number, it does indeed throw a PHP warning and treats it as a null input. My understanding is that it used to return 0 and that was considered a bug by some (although others, including the author of the function, decided that as the return type was a number it should ALWAYS return a number). The change that is under "dispute" in this case is that it has indeed been changed to return null, which is what most people now agree is the best way, and is consistent with other PHP functions.
I believe you are refering to strongly vs weakly typed, not statically vs dynamically typed. A strongly typed language would not try to parse the string into a number (although it would indeed accept a string, if it is dynamically typed as well).
First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)