Re: [PHP-DEV] Apply strict_types to internal functions
> // strict with internal func > declare(strict_types=1); > declare(strict_types='strict_with_internal_func'); > declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC); I made a mistake. Here is exactly: ``` // strict with internal func declare(strict_types=2); declare(strict_types='strict_with_internal_func'); declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC); ``` Saki
Re: [PHP-DEV] Apply strict_types to internal functions
I also skimmed over past discussions. I've found that having full control over `strict_types` globally is not a good idea. This is because it can break the behavior of many libraries, and developers don't always respond appropriately to this fix. So I came up with the following idea. Allows a new value of 2 for strict_types. However, since magic numbers make the code difficult to read, I thought it would be a good idea to also provide strings that can serve as constants and aliases. This could provide new options to users while safely maintaining backwards compatibility. example: ``` // weak declare(strict_types=0); declare(strict_types='weak'); declare(strict_types=STRICT_TYPE_MODE_WEAK); // strict declare(strict_types=1); declare(strict_types='strict'); declare(strict_types=STRICT_TYPE_MODE_STRICT); // strict with internal func declare(strict_types=1); declare(strict_types='strict_with_internal_func'); declare(strict_types=STRICT_TYPE_MODE_WITH_INTERNAL_FUNC); ``` I need more time to come up with a better name. Saki
Re: [PHP-DEV] Apply strict_types to internal functions
> 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. On second thought based on your point, it seems confusing to change the behavior of strict_types only for calls from internal functions. A minor problem is that there is no way to control strict_types for calls from internal functions. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
> Le 29 août 2023 à 18:40, Hans Henrik Bergan a écrit : > > * I think most code actually using strict_types=1 is built with the > assumption that internal functions use strict too, so it's entirely > possible that the backwards-compatibility issue is so small that we > can get away with internal functions just inheriting the userland > strict_types > > On Tue, 29 Aug 2023 at 18:36, Hans Henrik Bergan wrote: >> >> maybe we could do a >> declare(internal_strict_types=1); >> on a per-file basis just like the existing userland strict_types? >> (name is up for bikeshedding ofc) >> >> On Tue, 29 Aug 2023 at 17:49, Claude Pache wrote: >> [...] > Hi Hans Henrik, The rule of the mailing list is to post your answer below the text you are answering to, and to strip the parts of the original message that are not relevant to your answer. The aim is to make readers not to guess what you are responding to, and not to read backwards, thanks. Furthermore, I can’t connect your answer to any of the points I made in the specific email you replied to, so that you may have replied to the wrong email. —Claude -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
* I think most code actually using strict_types=1 is built with the assumption that internal functions use strict too, so it's entirely possible that the backwards-compatibility issue is so small that we can get away with internal functions just inheriting the userland strict_types On Tue, 29 Aug 2023 at 18:36, Hans Henrik Bergan wrote: > > maybe we could do a > declare(internal_strict_types=1); > on a per-file basis just like the existing userland strict_types? > (name is up for bikeshedding ofc) > > On Tue, 29 Aug 2023 at 17:49, Claude Pache wrote: > > > > > > > > > Le 29 août 2023 à 15:19, Saki Takamachi a écrit : > > > > > >> Hi, > > >> > > >> The larger issue is that higher-order functions do not inherit the > > >> `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 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
maybe we could do a declare(internal_strict_types=1); on a per-file basis just like the existing userland strict_types? (name is up for bikeshedding ofc) On Tue, 29 Aug 2023 at 17:49, Claude Pache wrote: > > > > > Le 29 août 2023 à 15:19, Saki Takamachi a écrit : > > > >> Hi, > >> > >> The larger issue is that higher-order functions do not inherit the > >> `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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: PHP-8.3 branch creation
On Thu, Aug 24, 2023 at 1:27 PM Jakub Zelenka wrote: > Hello, > > This is just a reminder that the PHP-8.3 git branch will be created on > Tuesday 29th Aug 2023. It means that the fixes for 8.3 will need to target > PHP-8.3 branch and master will be essentially for PHP 8.4. Also don't > forget to merge PHP-8.2 into PHP-8.3 and then PHP-8.3 to master for all > fixes after the branch is created. > The PHP-8.3 branch has been created and master is now for PHP 8.4. Please merge all bug fixes through PHP-8.3 from now on. Regards Jakub
Re: [PHP-DEV] Apply strict_types to internal functions
> Le 29 août 2023 à 15:19, Saki Takamachi a écrit : > >> Hi, >> >> The larger issue is that higher-order functions do not inherit the >> `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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Support optional suffix parameter in tempnam
On Tue, Aug 29, 2023, at 1:57 AM, Levi Morrison via internals wrote: > On Sun, Aug 27, 2023 at 4:20 AM Tim Düsterhus wrote: >> >> Hi Athos >> >> On 8/27/23 04:02, Athos Ribeiro wrote: >> > I am moving this RFC [1] to the voting phase. Voting will be open for the >> > next 2 weeks, until September 10th, as per https://wiki.php.net/rfc. >> > >> > [1] https://wiki.php.net/rfc/tempnam-suffix-v2 >> > >> >> I find this a useful feature in general, but I believe it not working on >> Windows completely nullifies the "could even provide more context for >> software processing such files" argument in favor of this feature. It >> will be unexpected for users if their code completely fails to work on >> Windows, because the suffix is ignored. >> >> For that reason I voted "no". >> >> Best regards >> Tim Düsterhus >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php > > > I have voted no for a similar reason. It would be nice if there were > os-specific packages in core that handled these kinds of things, > because the functionality is definitely useful. But if you call an API > like `FileSystem\Os\Unix\tempnam` then at least the platform specific > behavior is obvious and understood. I did as well. I am in favor of the functionality, but having it silently not-work on Windows is not a good approach. That may mean a larger refactoring of tempnam is a good next step, to fix the issues noted in the RFC and then support Windows consistently. I would support that, and including a suffix either with that or as a follow-up. (Side note: If messing about there, making prefix optional would also be wise so that it can be skipped via named args.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]
Hi, internals. I thought about various things to improve the current situation where `PDO::ATTR_ERRMODE` is not working very smartly. Exceptions may be thrown regardless of the setting of `PDO::ATTR_ERRMODE`. https://www.php.net/manual/en/pdo.rollback.php#refsect1-pdo.rollback-errors Another annoyance is that `PDO::ERRMODE_SILENT` sometimes gives a warning. This is an undocumented phenomenon, and it's a 19-year-old vintage bug. https://github.com/php/php-src/blob/223fb08819967b3063610289a5783944a85d6d65/ext/pdo/pdo_dbh.c#L74 Based on these, I feel that the reliability of the attribute value PDO::ATTR_ERRMODE is low and there is not much meaning in its existence as an attribute value. Since the default behavior became `PDO::ERRMODE_EXCEPTION` in PHP8.0.0, I think it would be better to abolish it rather than leave it halfway. I think this is a big change, so I'm assuming 9.x+ even if it's implemented. I will do the implementation myself. Please let me know what you think. Thank you. Saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
> Hi, > > The larger issue is that higher-order functions do not inherit the > `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. However, if you always inherit the strict_types of the PHP file that is the starting point of processing, in most frameworks the settings in “index.php" will affect everything. 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? saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
> Heya! > > I was not aware that strict types didn't work here. While I'm 100% behind > the idea, I am afraid that changing this will break code in currently > strict files where the assumption was made that it already worked like > that. It would probably have to give deprecation notices first, and then > possibly a warning or removal in the next major to be feasible. Hi, Thank you for confirming! Admittedly, it might be better to have some stages rather than a sudden change in 8.4. saki -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
> Le 29 août 2023 à 02:46, Saki Takamachi a écrit : > > Hello. > > I’m Saki Takamachi. > > Inspired by the issue below, I'm thinking of proposing this RFC. > https://github.com/php/php-src/issues/12055 > > As the documentation below states, PHP's internal functions currently ignore > strict_types. > https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict > > I think the current spec is not intuitive, > so I propose changing the behavior of the macro ZEND_ARG_USES_STRICT_TYPES() > to allow internal functions to accept strict_types. > > I plan to make changes in zend_compile.h and zend_compile.c and do the > changes myself, I haven't written any tests yet, but I'm thinking about > making changes like this. > https://github.com/SakiTakamachi/php-src/pull/1 > > As per How To Create an RFC, I will first try to gauge response to this > proposal on the mailing list. > > Thank you > > Saki Takamachi Hi, The larger issue is that higher-order functions do not inherit the `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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Apply strict_types to internal functions
On Tue, Aug 29, 2023 at 2:46 AM Saki Takamachi wrote: > Hello. > > I’m Saki Takamachi. > > Inspired by the issue below, I'm thinking of proposing this RFC. > https://github.com/php/php-src/issues/12055 > > As the documentation below states, PHP's internal functions currently > ignore strict_types. > > https://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict > > I think the current spec is not intuitive, > so I propose changing the behavior of the macro > ZEND_ARG_USES_STRICT_TYPES() to allow internal functions to accept > strict_types. > > I plan to make changes in zend_compile.h and zend_compile.c and do the > changes myself, I haven't written any tests yet, but I'm thinking about > making changes like this. > https://github.com/SakiTakamachi/php-src/pull/1 > > As per How To Create an RFC, I will first try to gauge response to this > proposal on the mailing list. > > Thank you > > Saki Takamachi > Heya! I was not aware that strict types didn't work here. While I'm 100% behind the idea, I am afraid that changing this will break code in currently strict files where the assumption was made that it already worked like that. It would probably have to give deprecation notices first, and then possibly a warning or removal in the next major to be feasible.
