Re: [RFC] Scalar Type Hinting With Casts (re-opening)

On Mon, 14 Jul 2014, Rowan Collins wrote: > Derick Rethans wrote (on 14/07/2014): > > A compromise by adding more inconsistencies. > > The only way of not introducing some inconsistencies (or, to put it another > way, new features) is to use strict type hints, which perform no casting, and > error on invalid input, since that's what the existing type hints do, in > particular "array". There's broad consensus that that wouldn't be very > "PHP-ish", and it has been rejected in previous discussions. I am quite aware of that. > Here are the main variants discussed in this thread: > > 1) add type hints using existing syntax, but which are actually silent casts, > rather than the strict validation performed for existing types > 2) add type hints using existing syntax, which are casts, but also act > differently from existing casts by emitting some kind of notice > 3) add cast hints using a new syntax > 4) add type hints using existing syntax, which use a new "lossless cast", i.e. > perform validation for completely wrong input ('abc' as an int param) but > allow juggling for "reasonable" input ('123' as an int param). > > Option 2 (or 3) could also be implemented by making *all* lossy casts emit > some kind of notice. > > This RFC currently proposes option 4. Yes. And with that option I have a problem, as nothing else does it like that now - hence my arguing against "a new set of casting rules". Option 1 is equivalent to my argument that this should be equivalent: function foo(int $var) {} function foo($var) { $var = (int) $var; } and called by f.e.: foo('123abc'); cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine