Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125221
Feedback-ID: id5114917:Fastmail
Message-ID: <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk>
Date: Sun, 25 Aug 2024 17:05:54 +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>
Content-Language: en-GB
In-Reply-To: <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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

To pull out a point that might be overlooked at the bottom of my longer 
response earlier:

 > As the RFC points out, library authors already worry about the 
maintenance burden of named argument support, will they now also need to 
question whether someone is relying on "default + 1" having some 
specific effect?

By saying "default can be used in any expression, as complex as the 
caller can imagine", we're implicitly saying "if you add a default to 
your function signature, that is no information a user can pull *out* as 
part of your API".

Regards,

-- 
Rowan Tommins
[IMSoP]