Arvids Godjuks wrote (on 14/07/2014):
We already have quite good implementation for the array and object hints, they do their job and do it good. No need to change those at all - leave them as is - no need to add magic with casts and all that. Function/method requires an array? Make casts explicitly and pass it an array and not an integer.
Yes, I totally agree. What I don't think makes sense is for the keyword "array" in a function signature to mean "error if a string is passed", but the keyword "int" in exactly the same place to mean "happily accept any string (or even an array) and cast it to int, even if it's a lossy conversion".
If there is to be a short-hand for casts in function signatures, it should not reuse the current syntax for type assertions, as they are not equivalent facilities.
But this automatic casting should work only between string, integer, float, bool and null types and only between these. No automatic casting of these 5 to arrays or objects.
Rather than special-casing this for "static types" (despite the fact that arrays *can* be cast from other types) I would prefer to see it only happen where it can be *lossless* (which is never the case for arrays, thus making the current logic consistent with the new rule). This is essentially what the current RFC proposes.
I don't think that's actually overthinking it any more than the scalar vs non-scalar version would, as it's a pretty easy rule to express. Broadly, if (source_type)(target_type)$var == $var, that's a lossless cast. (There are a couple of odd exceptions with very specific values, such as (int)(array)1 == 1, but it's not too much of a stretch to say "all array casts are considered lossy".)
You just need to get a warning, that you can disable via error_reporting, and just make your prototype with all the type hints you need and deal with the cast warnings in the type hints later on.
As I've said elsewhere, I see the usefulness of emitting warnings of some kind for "lossy" casts as a separate question from the usefulness of performing such casts inline in function signatures. It makes sense for the language to implement both at once, but for the user to be able to use them separately (e.g. catch lossy conversion in existing uses of (int)$foo).
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
