Even if Python 3's type conversion semantics has no dark corners, I still have a point.
harshreality argued that, because PHP's implicit type conversion leads to weird behaviour, "PHP doesn't work. End of story."
In that case, nearly every widely used language (with the possible exception of Python 3) "doesn't work. End of story." That's not a very interesting or useful story to tell.
8 is sane here. The + operator adds numbers. It converts the string to a number implicitly in the process. it takes "0x4zz5" and tries to parse as much as possible. Since "z" is not a valid hexadecimal digit, it stops at z, and reads it as 0x4.
Well, I'd say it's never better to "try to parse as much as you can" and when encountering such an error simply silently give out a nonsense answer.
It's the computer equivalent of a bozo worker who does something random everytime they don't know how to do their job, and then tries to hide any consequences while whistling innocently.
It's not equivalent at all. It is an expected, clearly-defined behaviour - automatic, silent type conversion, with clear rules on how that type conversion works.
I'd bet 1-to-10 that if someone uses '+' operator then that line of code is never expected to encounter "0x4zz5" there. And I'm pretty sure that this addition is not meant to return a number exactly 4 less if it encounters "0z4zz5" instead of "0x4zz5". There is some theoretical chance that it does, but really, it's a lottery-type chance.
The whole total function has something that it's expected to do, some value that it returns in the end - and if it can't do that then any returned value is useless and wrong anyway; and automatic, silent type conversion is the worst possible choice of action, since it not only doesn't work, returning a value that you didn't intend (as other options); but in addition makes the actual bug hard to find and potentially corrupts a lot of stored data before you find the bug.
Things like this and some interesting developments from Facebook concerning them are mentioned in the presentation, so it would be nice if people would actually discuss that. Just a suggestion.
It's PHP. Unfortunately, enough developer got bit by the fact that PHP doesn't prevent you from shooting yourself in the foot, and shot themselves in the foot.
So, you'd probably be pretty ornery too when other people had more discipline to use the language without shooting their foot and were also employing it successfully. You'd probably want to make assumptions, and word hard to belittle them. Insult them.
And they'll talk about beauty. And zen. And wonder, and joy in a language. And they'll gloss over the major problems that it suffers from. They'll imagine all is well. And they'll try and tell you that nothing good can come from the tool they once used to shoot themselves in the foot.
PHP may have a bunch of ways to shoot yourself in the foot, but you get a new foot back right away. IMHO the oddities in PHP rarely hit you, and when they do you'll pick it up right away in PHPUnit, fix it, and walk away.
As a PHP developer I entirely assume that is going to print 8. I'm sure every PHP developer has had it happen or ran across it in the manual: when strings are forced into int positions PHP uses the numbers from the front of the string. Its unexpected, but consistent.
You missed the point, and the problem. PHP tries way too hard to try to mangle input to kinda sorta work with the operators at hand. Were it a reasonable language, it would throw out a warning, or better yet, an error, to handle a fairly broken situation like this, rather than try to pick and choose the parts of the string it thinks is appropriate.
Implicit type conversion is evil, and I don't see how PHP's sin of favouring string -> number over number -> string is any worse than, say:
Or: