Re: Feedback for nullc Idea

From: Date: Tue, 25 Mar 2025 05:53:30 +0000
Subject: Re: Feedback for nullc Idea
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 3/23/2025 11:10 AM, Larry Garfield wrote:
I'm not sure it justifies a new pseudo-function language construct.
Fair enough.  Thank you for the feedback. On 3/23/2025 2:37 PM, Rowan Tommins [IMSoP] wrote:
It's telling that all your examples with ?? put a value other than null on the right-hand side.
I may have over-simplified the examples.  Comparing $input === 'yes' will have the same result whether $input is null or 'none' or an empty string.  So not implying a result type, just want to compare a literal or other variable to $input even when not declared. A different example could be if (coalesce($_POST['tick']) > 10) return;
In my experience, a lot of people struggle to follow logic like this, and it can easily lead to subtle bugs. Compare the same logic with explicit defaults: if (nullc($test, 'off') === 'on') if (nullc($test, 'on') !== 'off')
Having optional defaults seems fine.  Meanwhile... if ($test ?? 'on' !== 'on') will evaluate to true when $test is set to 'on'.
There is a small risk that some people might have an existing function with different behaviour, e.g. a test on "emptiness" with `$arg != false`, and need to rename it when upgrading PHP.
This is a good point.  I assume that risk exists for all new functions and needs to be considered.
I'm still only lukewarm on including it, because it's mostly just reminding you to include a pair of parentheses:
Think of it as a quick way to use an undeclared variable without having to explain operator precedence to other developers. In any case, thank you for the feedback.

Thread (10 messages)

« previous php.internals (#126929) next »