Hello internals,
Following the rejection of the operator overloads RFC I have looked at
bringing some mathematical improvements to PHP in extensions instead. As
part of this, there is one truly blocking issue:
The opcodes for == and != are handled by the compare handler.
On zend_class_entry, ext
On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider
wrote:
>
> My issue with this is that while it seems to work towards the goal of
> "fail fast" it does not completely fulfill its promise.
>
>
Pardon me, but this argument seems rather impotent. Only fully realized
features are allowed? What if
> Any type error should if you ask me. Unexpected types cause unexpected
> behavior, and the longer PHP will try to continue with assumptions of types
> and implicit casting, the bigger the damage can be. All this type juggling is
> headache material and the less I see of it, the better.
Sorry
On Fri, Jan 28, 2022 at 3:13 PM Robert Landers
wrote:
> I would posit differently. In my experience in upgrading code, it was
> mostly intentional.
> Here's an example:
>
>
> if($doThing) {
> $doOtherThing = maybe();
> }
> // later
> if($doOtherThing) {
> doOtherThing();
> }
> ---
>
> Th
Hi,
> So what we're talking about here is changing the engine's definition of
> what is safe
One of the benefits of PHP is it's resilience in the face of user input.
The
only time this isn't desired is in a security context (SQL queries,
authentication, etc). Most applications are not operating i
Am 27.01.2022 um 23:41 schrieb Mark Randall :
> What we don't want to do, I think, is end up in a situation like JS where it
> has to be opted in: https://www.w3schools.com/js/js_strict.asp
That's why the majority decided a while ago that you don't have to opt-in right
now: The default error_rep
