Hi Rowan
On Sun, Aug 25, 2024 at 6:06 PM Rowan Tommins [IMSoP]
<imsop....@rwec.co.uk> 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
I don't agree with that. Constant expressions in PHP already only
support a subset of operations that expressions do. However, default
is proposed to be a true expression, i.e. one that compiles to
opcodes. Looking at the `expr` nonterminal [1] I can't see any
productions that are restricted in the context they can be used in,
even though plenty of them are nonsensical (e.g. exit(1) + 2).
Furthermore, new in initializers was disallowed in some contexts not
because it would be nonsensical, but because it posed technical
difficulties.
I also believe some of the rules you've laid out would be hard to enforce.
> 1) The expression should be reasonably guaranteed to produce the same type as
> the actual default.
Even the simple cases of ??, ?: can easily break this rule.
Furthermore, context restriction is easily circumvented. E.g.
foo((int) default); // This is not allowed
foo((int) match (true) { default => default }); // Let me just do that
I'm not sure context restriction is worthwhile, if 1. we can't do it
properly anyway and 2. there are no technical reasons to do so.
Ilija
[1]
https://github.com/php/php-src/blob/3f4028d3d9d63e1dae012a9c350141493b30825f/Zend/zend_language_parser.y#L1198
