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 consi
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
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 "pro
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
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 doin
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 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 make
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 wa
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,
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
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 declarat
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 datast
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_i
13 matches
Mail list logo
