Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.176 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>
 <A1902C97-2854-44C8-AA76-2551DF3F05E5@ajf.me>
In-Reply-To: <A1902C97-2854-44C8-AA76-2551DF3F05E5@ajf.me>
MIME-Version: 1.0
Thread-Index: AQJuUFVOlGiX172RfpkkW7aXwqSXwwHleMkPAd/qfJcBzHP03AGqtGtJAmKS0moBHXfO1poMclIw
Date: Mon, 14 Jul 2014 19:04:40 +0300
Message-ID: <3b06c592b0b88bb95d3ae7ea7a93d86f@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
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: Andrea Faulds [mailto:ajf@ajf.me]
> Sent: Monday, July 14, 2014 6:49 PM
> To: Zeev Suraski
> Cc: Rowan Collins; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
>
>
> On 14 Jul 2014, at 16:46, Zeev Suraski <zeev@zend.com> wrote:
>
> > 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.
>
> How is emitting a new E_CAST useful? Most people are not going to write
> error handlers that will act on it, so it'll just be an E_WARNING so far
as most
> people care, and we'll just end up with casts, which you can already do:
>
>     function foo($a) {
>         $a = (int)$a;
>     }

I already mentioned before that I don't think consistency is a bad thing
(and that's an understatement).  Having the syntax differ and have a
separate, similar set of rules/behaviors is a disadvantage, not an
advantage in my book.

There are several advantages of adding this syntax with the simple casting
behavior:

1. It saves a bit of code and improves readability for a *very* common use
case.
2. It encourages developers to get the types straight instead of relying
on implicit casts.
3. It reuses syntax we already use for type hinting so it doesn't drive
complexity up significantly.
4. It allows people to go extra strict very easily, by turning E_CASE into
errors.  My guesstimate is that the majority of people won't, but it'll be
possible and easy to do nonetheless.
5. It maintains consistency with casts (that's a feature, not a bug :)

Zeev