[paledot]

Worth emphasizing that this directive applies per file, and affects functions called (not those defined) in that file. Not sure if there's a mechanical reason for that, but if I'm writing a new class I'd like some assurances that it's being used correctly. If I could enforce strict types on calling code, I could do away with a certain class of validation.

[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.

[wolco]

Make the changes in your php.ini

Use a configure file that sets env variables for your project files. Put call in that file.