[makeitdouble]

Yes, except it has to be set on the _caller_ side.

I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the strictness set. [0]

So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.

[0] Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system. And it still doesn’t work for native functions.

It’s so close. Really, so close to be good.

[jbboehr]

> Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system

There was this RFC[0] but it seems to have fizzled.

> And it still doesn’t work for native functions.

The page states: 'Function calls from within internal functions will not be affected by the strict_types declaration' (emphasis mine). Outside of array_map I don't think this happens all that much.

> So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.

That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?

[0]: https://wiki.php.net/rfc/namespace_scoped_declares

[makeitdouble]

> native functions

Thanks

> That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?

It is completely unelegant, but works decently in practice (fits the subject perfectly…). We’re extensively using phpstan, especially as it’s the best way to expose in array types.

Phpstan still has blind spots, including the ability to disable it on the caller side (in particular, as far as I know you can’t disable specific errors inline, so if you have to do it for one parameter for instance, it applies to all parameters), and the option to overwrite a variable type just for phpstan. Those comes from developer error, but that’s exactly what we want to protect the system from.

Actually checking at runtime that a value is of the right type is more secure.