[zerocrates]

The point is supposed to be that once you write in a scalar typehint for a parameter, you don't need to do validation for it being the right type within the function: even if it's called from a non-strict context, that just means PHP will cast it before passing it. So you can avoid type checking code in your function but consumers can still use the more traditional and dynamic style of PHP if they want to.

I can't quite think of the type of validation you'd be able to avoid with the sort of "inverted" strictness you're describing.

Certainly I can think of issues people could have if not using strict types (basically, unexpected casts), but not things that you could actually validate from within the function.

[paledot]

Good point. My method may behave unexpectedly if you call `sum(true, false)`, but it's not identifiably different than `sum(1, 0)`. Sorry, it was late, and I failed to mention my actual use case: I work on a legacy application and want to enforce correctness on the new code I write. I'd rather write a new module and enforce that the calling code in the legacy app is using it correctly, than try to add strict types to the legacy classes.