On 25 Jul 2014, at 20:20, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> This makes very little sense, 0 means the same as false is in many > contexts in PHP and also in many languages. It also means very different things in some places, particularly return values. strpos returning 0 is most definitely not the same thing as strpos returning FALSE. That’s a big reason why FALSE and TRUE aren’t accepted for int type hints: bools are common error values. > Having random arcane rules > would only make the users curse us every time they get tripped by them. The rules are not random nor arcane. > I call everybody to vote against this RFC - it's better not to have such > thing at all then to promise our users improvement only for them to > discover this improvement is fraught with inconsistent arbitrary rules How are they inconsistent and arbitrary? These rules haven’t been picked at random from a hat, they’ve come from a process of careful thought. Casting an integer to a string and vice-versa makes sense and is a common operation ($_GET[‘id’]), while casting a NULL or FALSE to a string doesn’t really make sense (when do you need to do this?), and is unlikely to happen unless something’s gone wrong. > that do not match what the rest of the language is doing That is true, but it would be possible to change zpp later. > - even within > the same context of the function call. I can see no uniting principle > behind this table, which is randomly strict and randomly non-strict > without connection to the rest of PHP. I do not think it is the right > thing to have such thing in the language, even if it would help > somebody's particular use-case. The point of this RFC is to strike a compromise that is generally useful rather than helping one specific use case (strict hints) or another (casts). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
