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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
