Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75433
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <53C2C84A.6060308@garfieldtech.com>
Date: Sun, 13 Jul 2014 12:56:26 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com> <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com> <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com> <53C29EE4.3090808@gmail.com> <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com> <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me> <b3026b451453e3c2412bbf45c59f5003@mail.gmail.com> <53C2AF35.40003@gmail.com> <93bb0c689ccca03a0af46c51abf0e11f@mail.gmail.com>
In-Reply-To: <93bb0c689ccca03a0af46c51abf0e11f@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: larry@garfieldtech.com (Larry Garfield)

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