Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 24/02/2022 02:31, Bob Weinand wrote: However, should your RFC pass, it is not possible to say "hey, I generally consider this a low impact class of errors, please try to continue". This is correct. As the custodians of the language, it is our responsibility to decide what the engine considers low / high impact and act accordingly. In some cases users get the choice, but in most cases we make the choice for them. We have internals and the voting system precisely for this reason, to have a broad number of voices involved in those decisions. If users wish to use the latest versions, they must ensure they meet its requirements, this is really no different than any other BC break we do for the good of the language and its users. A couple of years ago we voted to promote 13 things to become errors / type errors, and I note you voted in favour of 12 of them, without requiring an opt-out. I must therefore assume you consider the use of undefined variables to be a legitimate coding style, and that's fine if that is your position. This RFC boils down to internals deciding, as a group, that it isn't one we want to support in future. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Hey Mark, For me, there's a fundamental shortcoming of this proposal: - You cannot opt out. Currently, as you describe in your RFC, it is perfectly possible, to opt into making this category of errors fail hard (throw an exception in an error handler). However, should your RFC pass, it is not possible to say "hey, I generally consider this a low impact class of errors, please try to continue". As such, given that PHP is meant to appeal to a broad class of use cases, I am strongly against this change as proposed. Bob > Am 18.02.2022 um 00:28 schrieb Mark Randall : > > Internals, > > Following on from my previous thread, I think we are now in a position where > we can begin formal discussions on an RFC to promote undefined variables to > Error exceptions in PHP 9.0. > > I present: > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > I still intend to bring other error promotions forward, potentially in > collaboration with other developers, but as this is the biggest change, and > the most likely to attract a large number of comments, I thought it deserving > of a standalone RFC. > > Mark Randall > > -- > 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] [RFC] Undefined Variable Error Promotion
On 23/02/2022 19:32, Rowan Tommins wrote I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. It is already part of the RFC within the "proposed PHP versions" section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 18:42, Mark Randall wrote: It may be that in 8.2 if this RFC passes that message will change to include "This will throw an error in PHP 9" I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. I used a similar approach in https://wiki.php.net/rfc/deprecate-bareword-strings because I wanted the visibility of E_WARNING but the clear mention of deprecation. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 18:02, Nicolas Grekas wrote: I mean in addition yes, deprecation before warning. I don't see this happening. An engine warning is as stark a mechanism as we have available that you either made a mistake, or shouldn't be doing something, without preventing you from actually doing it. It may be that in 8.2 if this RFC passes that message will change to include "This will throw an error in PHP 9", but giving multiple messages for it is not beneficial IMO. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Yeah, please don't: yet another side effect, deep in some `vendor` cruft. Just stop it, please: I almost have PTSD from 8.1. On Wed, 23 Feb 2022, 19:02 Nicolas Grekas, wrote: > Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a > écrit : > > > On 23.02.2022 at 16:29, Nicolas Grekas wrote: > > > > > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a > > écrit : > > > > > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < > > >> nicolas.grekas+...@gmail.com> wrote: > > >> > > >>> But this makes me think: we should trigger a deprecation just before > > all > > >>> corresponding warnings! > > >> > > >> Please, no more deprecation warnings, make it stop > > >> Yes, undefined variables are a problem, but I just spent 6 months in > > >> `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but > > >> frustration: this stuff is statically introspectible, and even more > > >> side-effects are just more trouble. > > > > > > I'm not going to be affected by this RFC at all, and neither are you, > > since > > > we use throwing error handlers. But ppl that do rely on code bases that > > > have undefined vars "by design" will be. I would bet that the number of > > ppl > > > in that affected group and that also use a static analyser is very very > > > small. This means that static analysers are not a pragmatic solution > > here. > > > > That. > > > > > Ppl that don't use static analysers deserve a prior notice. There is a > > > dedicated reporting mechanism in place and we should use it IMHO. With > > new > > > deprecations added to PHP 8.1, the ecosystem realized that the tooling > > > needed to improve - and it did (phpunit, Laravel, etc.). We can and > > should > > > add new runtime deprecations when planning a BC break. > > > > > > Please consider adding this deprecation Mark (and others.) > > > > Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I > > wouldn't be happy either way. > > > > I mean in addition yes, deprecation before warning. > > I considered grouping them as E_DEPRECATED|E_WARNING but that'd break many > userland error handlers I fear. >
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a écrit : > On 23.02.2022 at 16:29, Nicolas Grekas wrote: > > > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a > écrit : > > > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < > >> nicolas.grekas+...@gmail.com> wrote: > >> > >>> But this makes me think: we should trigger a deprecation just before > all > >>> corresponding warnings! > >> > >> Please, no more deprecation warnings, make it stop > >> Yes, undefined variables are a problem, but I just spent 6 months in > >> `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but > >> frustration: this stuff is statically introspectible, and even more > >> side-effects are just more trouble. > > > > I'm not going to be affected by this RFC at all, and neither are you, > since > > we use throwing error handlers. But ppl that do rely on code bases that > > have undefined vars "by design" will be. I would bet that the number of > ppl > > in that affected group and that also use a static analyser is very very > > small. This means that static analysers are not a pragmatic solution > here. > > That. > > > Ppl that don't use static analysers deserve a prior notice. There is a > > dedicated reporting mechanism in place and we should use it IMHO. With > new > > deprecations added to PHP 8.1, the ecosystem realized that the tooling > > needed to improve - and it did (phpunit, Laravel, etc.). We can and > should > > add new runtime deprecations when planning a BC break. > > > > Please consider adding this deprecation Mark (and others.) > > Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I > wouldn't be happy either way. > I mean in addition yes, deprecation before warning. I considered grouping them as E_DEPRECATED|E_WARNING but that'd break many userland error handlers I fear.
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23.02.2022 at 16:29, Nicolas Grekas wrote: > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit : > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < >> nicolas.grekas+...@gmail.com> wrote: >> >>> But this makes me think: we should trigger a deprecation just before all >>> corresponding warnings! >> >> Please, no more deprecation warnings, make it stop >> Yes, undefined variables are a problem, but I just spent 6 months in >> `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but >> frustration: this stuff is statically introspectible, and even more >> side-effects are just more trouble. > > I'm not going to be affected by this RFC at all, and neither are you, since > we use throwing error handlers. But ppl that do rely on code bases that > have undefined vars "by design" will be. I would bet that the number of ppl > in that affected group and that also use a static analyser is very very > small. This means that static analysers are not a pragmatic solution here. That. > Ppl that don't use static analysers deserve a prior notice. There is a > dedicated reporting mechanism in place and we should use it IMHO. With new > deprecations added to PHP 8.1, the ecosystem realized that the tooling > needed to improve - and it did (phpunit, Laravel, etc.). We can and should > add new runtime deprecations when planning a BC break. > > Please consider adding this deprecation Mark (and others.) Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I wouldn't be happy either way. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit : > On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> >> But this makes me think: we should trigger a deprecation just before all >> corresponding warnings! >> > > Please, no more deprecation warnings, make it stop > Yes, undefined variables are a problem, but I just spent 6 months in > `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but > frustration: this stuff is statically introspectible, and even more > side-effects are just more trouble. > I'm not going to be affected by this RFC at all, and neither are you, since we use throwing error handlers. But ppl that do rely on code bases that have undefined vars "by design" will be. I would bet that the number of ppl in that affected group and that also use a static analyser is very very small. This means that static analysers are not a pragmatic solution here. Ppl that don't use static analysers deserve a prior notice. There is a dedicated reporting mechanism in place and we should use it IMHO. With new deprecations added to PHP 8.1, the ecosystem realized that the tooling needed to improve - and it did (phpunit, Laravel, etc.). We can and should add new runtime deprecations when planning a BC break. Please consider adding this deprecation Mark (and others.) Nicolas >
Re: [PHP-DEV] [RFC] Allow null and false as stand-alone types
On Sun, Feb 20, 2022 at 6:56 PM G. P. B. wrote: > Hello internals, > > As a follow up from the "Allow null as a stand-alone type" where the main > talking point was to also allow false to be used as a stand-alone type, a > new slightly modified RFC is now proposed: > https://wiki.php.net/rfc/null-false-standalone-types > > The implementation has been updated to reflect the new RFC. > The new RFC has a link to implementation and a link to the previous RFC (which has a link back to the new one) but I had to search for the original *discussion*, so here it is: https://externals.io/message/116188 (+1 for me, with or without false) Regards, -- Guilliam Xavier
Re: [PHP-DEV] Allowing NULL for some internal functions
On Tue, Feb 22, 2022 at 3:59 AM Alexandru Pătrănescu wrote: > On Mon, Feb 21, 2022 at 5:32 PM Craig Francis > wrote: > > > On Mon, 21 Feb 2022 at 09:04, Christoph M. Becker > > wrote: > > > > > That "inconsistency" had been introduced with PHP 7.0.0, i.e. right > when > > > scalar type declarations have been introduced. Passing a null to a > > > non-nullable parameter of a *userland* function throws a TypeError > > > > > > > > > Thanks Christoph, that's a good way of looking at it. > > > > Considering NULL has been passed to these internal function parameters > for > > years, for a variety of reasons, and PHP has coerced it into an empty > > string, integer 0, float 0, or boolean false... I'm wondering if my RFC > > should focus on matching that expectation, so anyone not using > > `strict_types=1` does not need to make loads of hard-to-find/unnecessary > > edits; that way NULL would be treated the same as the other variable > types > > (I appreciate arrays and objects don't get coerced, but I don't think > > anyone expects them to). > > > > Yes, exactly that. > A few weeks ago when the issue was mentioned again I had to remember by > trying on 3v4l myself that using null for a string parameter wasn't an > automatically coerced case when strict_types = 0. > For history: https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks (**emphasis** mine): > A weakly type-checked call to an extension or built-in PHP function has exactly the same behaviour as it did in previous PHP versions. > > The weak type checking rules for the new scalar type declarations are **mostly** the same as those of extension and built-in PHP functions. The only **exception** to this is the handling of `NULL`: in order to be **consistent with our existing type declarations for classes, callables and arrays**, `NULL` is not accepted by default (...) In hindsight, maybe that wasn't the most "fortunate" decision... (although, fair enough, `NULL` was never considered to be "scalar") > > In my view, false would have the same problem for those internal functions. > Why should it be coerced to an empty string? > https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg#proposal is > all about removing the automatic coercion that was happening for null in > the internal functions > Planning that in PHP 9 the type interpretation for internal function will > be done the same as for user defined functions. Consistency. > > (...) > > As I mentioned, coercing false to int would be for me almost as bad as > coercing null to int. > But when types are not considered important I think it's worth pursuing > extending the coercion from null to the 4 other types where it's happening > right now: > - int as 0, > - float as 0.0, > - string as an empty string > - bool as false. > Indeed, that could also be a way to solve the original (PHP 7.0) inconsistency between internal and user-defined functions (although PHP 8.1 started to take the opposite route...) > > I don't like it and I have no good idea how that would work as it would be > a pretty big BC break. > > Maybe it would be easier to change strict_types to default to 1 in PHP 9 > along with adding the null coercion for null when strict_types is 0 rather > than inventing a new strict_types value like -1 that would allow null > coercion as well. > Starting with a notice in PHP 8.2 when the directive is not present might > be an interesting starting point. And no more warning for implicit coercion > when strict_types=0 directive is explicitly defined as it would not change > anymore in PHP 9. > Or maybe (if going directly from error to implicit coercion is deemed too "risky") the current TypeError in non-strict_types mode (when passing NULL to a user-defined function expecting a scalar) could first be "demoted" to some kind of Notice [who said E_STRICT] in 8.2 (along with reverting the Deprecation added in 8.1 for internal functions) and removed in 9.0? -- Guilliam Xavier
Re: [PHP-DEV] Adding `class UnsupportedOperationException extends RuntimeException` to php?
Hi Tyson On 2/13/22 16:50, tyson andre wrote: Currently, there doesn't seem to be an exact fit for indicating that a method isn't supported on an object by design (and will throw unconditionally). (For example, when implementing an interface or overriding a base class, e.g. an Immutable datastructure not implementing offsetSet/offsetUnset, an object that does not support serialization and overrides __serialize/__unserialize to forbid it, etc.) […] Thoughts on adding UnsupportedOperationException to the spl? The "Redacting parameters in back traces" RFC has the same issue for the SensitiveParameterValue::__unserialize() method [1] which is not supported by design. In userland I'd commonly use BadMethodCallException for this purpose, but thinking about it: A `LogicException` is not really fitting for the reasons you outlined. UnsupportedOperationException sounds like a useful addition to me. [1] https://wiki.php.net/rfc/redact_parameters_in_back_traces#choice_of_replacement_value Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Redacting parameters in back traces
Hi Internals! On 2/22/22 13:25, Tim Düsterhus, WoltLab GmbH wrote: As a reminder: Voting for the "Redacting parameters in back traces" RFC closes in a little more than 25 hours. I just closed the vote. The "Redacting parameters in back traces" RFC https://wiki.php.net/rfc/redact_parameters_in_back_traces was accepted with 24 (Yes) to 1 (No) votes (96% acceptance). Thanks to all of you who participated in the discussion and the voting process. I'll proceed with cleaning up the git history of the implementation at https://github.com/php/php-src/pull/7921 so that it can be reviewed. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
