On 07/13/2014 11:28 AM, Zeev Suraski wrote:
Again, option #1 as I see it (and is mostly described in the 2010 RFC
https://wiki.php.net/rfc/typecheckingstrictandweak) - it's identical in
terms of rules to those of PHP's casting, but with warnings emitted for lost
data and 'bogus' conversions.  If we introduce this feature in a major
version, we could also consider change the casting code to emit these same
warnings so that we get full consistency - but that I think is in fact a
separate decision.

Zeev

I want to call out this point because I think it's key. Remember that when an E_* is emitted, if it's not trapped then code execution continues. That means we can, and should, think about what the resulting value is independently of what if any E_* message is emitted.

That is:

function give_int(int $foo) { }
give_int('123abc');

The value of $foo should be 123 (int), because that's what casting rules say. However, because that's lossy an E_* should get emitted to warn the developer "hey, not what I meant!" If the error handler doesn't terminate the process, though, then give_array() will continue to execute and in that case the value that results from the cast MUST be the same as if it were done explicitly.

We can discuss when the E_* should be emitted separately from what the cast result is.

The one caveat to that is arrays, as someone else noted:

Current PHP:

function give_array(array $foo) { var_dump($foo); }
give_array('abc');
// Catchable fatal error.

Whereas if it follows the hint rules, apparently:
array(1) { [0]=> string(3) "abc" }

Which as a developer I wouldn't want, since that's likely to break my code's assumptions. Array is weird in that we'd be changing from a type specifier to a type caster. (ie, less like objects, more like primitives.) As long as it's an error of some kind it may be OK, but perhaps we want to leave array as is (strict behavior) rather than changing it to the primitive logic (cast behavior)?

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to