> -----Original Message----- > From: Andrea Faulds [mailto:a...@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 <z...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
