Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125233
Message-ID: <6afeb23a-867f-457d-9b13-fdf5af02c31e@scriptfusion.com>
Date: Sun, 25 Aug 2024 21:00:03 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: internals@lists.php.net
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
 <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk>
Content-Language: en-GB
In-Reply-To: <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: bilge@scriptfusion.com (Bilge)

On 25/08/2024 17:05, Rowan Tommins [IMSoP] wrote:
> On 25/08/2024 16:29, Bilge wrote:
>> You can write, `include(1 + 1);`, because `include()` accepts an 
>> expression. You will get: "Failed opening '2' for inclusion". Should 
>> we restrict that? No, because that's just how expressions work in any 
>> context where they're allowed.
>
>
> I think a better comparison might be the "new in initializers" and 
> "fetch property in const expressions" RFCs, which both forbid uses 
> which would naturally be allowed by the grammar. The rationale in 
> those cases was laid out in 
> https://wiki.php.net/rfc/new_in_initializers#unsupported_positions and 
> https://wiki.php.net/rfc/fetch_property_in_const_expressions#supporting_all_objects
>
They do not seem like better comparisons because, in both cases, support 
for those respective features was limited due to technical obstructions. 
My implementation already permits `default` as a general expression 
(thanks to Bob's Bison patch), Q.E.D. there is no technical constraint 
precluding support for default as a general expression grammar. What you 
are proposing is an artificial limitation on the language, which is an 
entirely different proposition (and not a healthy one, in my view).

Allow me to address the point made in your previous email which ended up 
hinting that `default + 1` should also be prohibited because it hasn't 
been explicitly justified.

Notwithstanding I don't have the energy to justify every single 
permutation of expressions, I'll humour the arithmetic operators 
criticism with an example just to demonstrate that one can justify just 
about anything with sufficient enthusiasm and creativity.

Suppose we have a Suspension class that suspends the current process for 
a specified delay in milliseconds, but our subclass wants to present an 
interface that deals with whole seconds (including fractional seconds 
using floats).

class Suspension {
     /**
      * @param int $delay Specifies the delay in milliseconds.
      */
     public function suspend(int $delay = 1_000) {
         var_dump($delay);
     }
}

class MySuspension extends Suspension {
     /**
      * @param float|int|null $delay Specifies the delay in seconds.
      */
     public function suspend(float|int|null $delay = null) {
         parent::suspend((int)(($delay ?? 0) * 1000) ?: default);
     }
}

new MySuspension()->suspend(2.2345); // int(2234)

Not only have I demonstrated the need to use multiplication or division 
to change the scale, but also the need to cast.

Cheers,
Bilge