> int $a = "1"; // no error. 1 == "1" so who cares? > int $a = 'House'; // error 0 != 'House', so this is a problem.
For the sake of consistency, please take into account this example, which works in the current implementation of PHP: $b = 1 + "1"; // no error, $b == 2 $b = 1 + "House"; // no error, $b == 1 So, I believe that, raising an error or not, is not a question of the new RFC. Should there be an error, then it has to be in every unsuccessful type juggling, regardless of the final assignment to a type-locked variable. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/2/29 Michael Morris <dmgx.mich...@gmail.com> > Agreed. If conversion can occur without data loss (that is, if the > value being assigned is == the value that actually IS assigned) then > no error should occur. > > So > > int $a = "1"; // no error. 1 == "1" so who cares? > int $a = 'House'; // error 0 != 'House', so this is a problem. > > Again, errors should only raise if the final value != source value. > > On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer <vch...@developersdesk.com> > wrote: > > On 2/28/2012 2:58 PM, Kris Craig wrote: > > > >> strong int $a = "1"; // Converts to 1. May or may not throw an error > (I'm > >> still on the fence). > > > > > > It this is an error, it is no longer PHP. > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
