On 13/07/2014 19:21, Andrea Faulds wrote:
On 13 Jul 2014, at 18:56, Larry Garfield <la...@garfieldtech.com> wrote:
We can discuss when the E_* should be emitted separately from what the cast
result is.
Is there any actual controversy over what the *result* of casts should be. This
RFC just has the normal casting result. Is anyone really in disagreement there?
Well, I think the behaviour of ' 42' and '42 ' passed as int could be
worth reviewing.
As long as it's an error of some kind it may be OK, but perhaps we want to
leave array as is (strict behavior) rather than changing it to the primitive
logic (cast behaviour)?
I think the discussion about how arrays should be casted too for consistency is
a bit silly. What makes sense for non-scalar types (strict hinting) may not
work so well for scalar types; casting to array is rarely useful, while casting
to the scalar types is readily.
I'm not sure I agree with this. I regularly use foreach( (array)$foo as
$bar ) for instance - it has the convenient behaviour of looping zero
times for null, once for a scalar, and leaving an existing array alone.
Objects are definitely a different case, because they have a lot of
unique behaviour (class hierarchies, additional reference indirection,
etc). It sometimes makes sense to bundle arrays with objects, in terms
of "scalar vs non-scalar", but other times it makes more sense to think
of "simple types (including arrays) vs objects". A mutable, unbounded
string isn't really "scalar" in the same way as a fixed-size integer,
anyway.
Also, frankly, function foobar((int) $a, array $b) is inconsistent and ugly.
Ugly, maybe, but less inconsistent than having function foobar(int $a,
array $b) { } foobar('a', 'b'); perform a cast to 0 on $a but a fatal
error for $b.
If there were a mixed syntax, you'd probably be using the cast type for
both anyway: function foobar((int) $a, (array) $b)
Still, the mixed validate-and-cast approach of this RFC gets around this
nicely, because there is no "safe cast" to an array available, so no
case that needs addressing. This doesn't really have to do with it being
"non-scalar" per se, just that there's no "natural" type-juggling like
there is for '123' => int or '1.5' => float.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
