> 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 <[email protected]>
> 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 <[email protected]>
> 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
>
>