Re: Apply strict_types to internal functions

> Le 29 août 2023 à 15:19, Saki Takamachi <saki@sakiot.com> a écrit : > >> Hi, >> >> The larger issue is that higher-order functions do not inherit the ���q >> ��U��ku���strict_types mode from its calling code, and this is not specific to >> internal functions. >> >> If you intend to change that for internal functions (with proper deprecation period, of >> course), you might consider making such a behaviour also possible for userland functions (probably >> using some opt-in); so that future higher-order internal functions do not become impossible to >> polyfill. >> >> —Claude > > Hi, thank you for confirming. > > If you simply put the problem you pointed out in the code, would it be something like this? > > https://gist.github.com/SakiTakamachi/8292dbfe92a2029a6c7b506b12296b7d > > Admittedly, I don't think this is intuitive either. That might not be intuitive to you, but it follows directly from the specified semantics: whether a function is called in strict_types mode or not, depends only on where the function is called. I personally doubt that there is an easy way to adjust the rule in order to make it both “intuitive” and simple. > > [...] > > When considering the inheritance of strict_types, I think that it should be an attribute that > can be set in “php.ini" instead of being specified for each file. > > What do you think? Beware that there are many third-party packages that have not opted for strict_types=1; if you enable that mode globally, you might make those packages malfunction. As I have just checked, among the packages I’ve installed via composer, there are more packages that do not use strict_types=1, than packages that use it. Among those that don’t use strict_types, the following ones are fairly common: google/apiclient league/oauth2-client michelf/php-markdown microsoft/microsoft-graph phpmailer/phpmailer phpoffice/phpspreadsheet phpseclib/phpseclib —Claude