Stas Malyshev wrote (on 15/07/2014):
IMO, having consistent rules is much more, orders of magnitude more important than serving any particular use case
We are adding a new feature to a language which is already inconsistent. We can only make it consistent with one part of the language by making it inconsistent with another.
If we take consistency as such a priority that we create a feature that is not actually useful, we will have wasted our effort, and made the language worse, not better. Saying "who cares if its useful, as long as it matches some other part of the language" is a very poor argument IMO.
That's an extreme, and I'm not saying anyone is saying precisely that, but I am getting rather weary of the back-and-forth over what is "consistent", rather than thinking about what we want to achieve, and what is the best way to achieve that.
What you want is strict typing then.
No, I want to introduce the notion of a "lossless cast", allowing things like (int)'123' to be valid. This distinction has been explained many times.
And if() working the same way - after all, if function can be unaware of the flag, if() is definitely unaware of it.
Not necessarily. An if() statement is clearly and unambiguously working with boolean values. Anyone looking at if( $foo & BIT_FLAG ) can know, based on basic knowledge of the language, that an implicit cast is taking place.
Someone looking at my_super_function( $foo & BIT_FLAG ) cannot know whether that parameter is being interpreted as a boolean or is actually being measured against that same BIT_FLAG (or some other integer operation) without consulting the source code (or, at least, trusting the documentation).
I am not among them. If you want to enforce code style, we already have tools for that, but I don't think this particular one should be in the language.
The logical conclusion from that is not to have type hints at all. So far, that is in fact the only consensus the PHP community has ever reached - not to have scalar type hints. (I don't mean that you necessarily hold that position, but it is the logical conclusion of that particular line of reasoning.)
Regards, Rowan Collins -- [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
