On 14 Jul 2014, at 15:03, Rowan Collins <rowan.coll...@gmail.com> wrote:
> Looking at the current table in the RFC, I'm not clear why NULL should pass
> as any value, but not array. Could it not behave the same as the existing
> type hints, i.e. accepted only if declared as a default?
>
> function foo(array $bar) { } foo(null); // ERROR
> function foo(array $bar=null) { } foo(null); // OK, $bar == NULL
> function foo(int $bar) { } foo(null); // ERROR
> function foo(int $bar=null) { } foo(null); // OK, $bar == NULL
I’m thinking this as well. I wonder if perhaps it should be casted by default,
but if you make it explicitly nullable, it won’t cast if NULL is passed.
> In summary, I think if the rules can be explained concisely, and the table
> derived from those rules, it will feel less confusing than having to consult
> the table to be sure of the effect.
>
> Having to say "for arrays, the logic is this; for strings, this; for
> integers, this; for booleans, the other" makes the whole thing seem like a
> bit of a kludge, and is exactly what the existing "lossy" casts suffer from.
>
> I would stress that I see this as a new definition of "lossless cast"; this
> RFC is intentionally *not* using the existing cast logic, as explicit casts
> *never fail*, so "but existing casts work this way" is not relevant.
Right. I’d like the rules to be simple enough. I think the string, int and
float ones make perfect sense and can be easily explained, it’s bool I’m
uncertain about.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
