Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75487
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>	<alpine.DEB.2.10.1407141536380.4247@whisky.home.derickrethans.nl>
	<AF61F548-FADC-428F-B76F-1BB82C645D2C@ajf.me>	<alpine.DEB.2.10.1407141552290.4247@whisky.home.derickrethans.nl>
	<53C3F70A.7010706@gmail.com>	<3aa29e080d70c843713e19a952dfbad6@mail.gmail.com>
 <CAAyV7nGMb=nn-_k9MHictPyGLeSfVSSwrzEZs37Ab0PV08GoFw@mail.gmail.com>
In-Reply-To: <CAAyV7nGMb=nn-_k9MHictPyGLeSfVSSwrzEZs37Ab0PV08GoFw@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwHleMkPAd/qfJcBzHP03AGqtGtJAmKS0moDKVd2+Jn8HLPA
Date: Mon, 14 Jul 2014 19:46:36 +0300
Message-ID: <8894514a1a05f5cb9b6272a4e289effe@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Monday, July 14, 2014 7:25 PM
> To: Zeev Suraski
> Cc: Rowan Collins; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
> Zeev,
>
> > Actually there's a pretty simple way that's not strict type hints:
> >
> > 5) Add type hints using existing syntax, which are casts;  Change
> > casts (both existing and these new ones) to emit a new E_CAST in case
> > of data loss or 'bogus' conversions.
>
> The issue with this, is that it changes how your calling code will behave
> based
> on global configuration. Not an issue for the application developer (since
> they
> can control the global config), but for a library developer who makes
> reusable
> code, this is going to become a nightmare to deal with.
>
> Example:
>
>     function foo(int $bar) {}
>     foo("12abc"); // May silently succeed. May raise E_CAST error. May
> throw
> exception. Who knows!

That's true for E_RECOVERABLE_ERROR in the exact same way.  We're only
arguing the 'default', in both cases the actual behavior will be affected by
global error handlers if they exist.

> That sounds like it's not a big deal, but it will result in calling code
> needing to
> get extra defensive to be robust:
>
>     try {
>         foo($something);
>     } catch (\Exception) {
>         // I have no idea what exception may have been thrown here
>     }
>
> Or ignoring the error entirely by "forcing" the unknown value to an
> integer:
>
>     foo((int) $something);
>
> Which is exactly what this RFC was designed to avoid.

I fail to see how it avoids it...  An app developer using an API that
expects an int, and that has an integer-looking-string coming from the end
user or a file, will simply stick an (int) there to avoid the API from
complaining about extra spaces or even superfluous characters.

> And that also hints towards a benefit of adding a numeric hint as well
> (which
> will accept (and cast to) either an int or a float, exactly how
> is_numeric_string() does internally)... Which is something that may want
> to be
> considered for this RFC.

I definitely agree with this one (it's in
https://wiki.php.net/rfc/typecheckingstrictandweak )

> That would again result in (int) casts being used, which would then hide
> the
> *real* error cases, such as passing "apple" to a function expecting an
> integer...

If you care about it - you can easily spot it by paying attention to
E_CASTs.  We're talking about runtime errors either way, if there was a way
to do 'compile time' error checking I'd see the point in going for errors,
but there isn't.  And as a special bonus, if we change the casting code to
also emit E_CAST - then we don't just push people to find "apple" -> int
issues in that specific situation, but everywhere where there's a cast.

Zeev