On 14 Jul 2014, at 15:03, Rowan Collins <rowan.collins@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/