Re: PHP True Async RFC - Stage 2

On 19 March 2025 15:51:38 GMT, Edmond Dantes <edmond.ht@gmail.com> wrote: >> >> "Cheating" in the sense that you wrote out a "general syntax", >> >I got it. > >> That's not the problem; the problem is that the following are all >equivalent expressions: >> (((foo()))) > >In principle, this is not a problem because the expression in parentheses >preceded by spawn is unambiguously a call expression. >That is, from an analysis perspective, everything is fine here because the >expression spawn () is a syntax error. This has nothing to do with my examples. If you start with a valid expression, you can add any number of parentheses around it, and get another valid expression, with the same meaning. A function call is an expression, and a function call wrapped in parentheses is another way of writing the same expression. But even though we're talking in circles about why, your latest examples do avoid the particular problem I was trying to describe. >From the user's perspective, what is the difference between these two >expressions? > >```php >spawn function(): string { ... }; >spawn (function(): string { ... }); >``` Yes, that would probably be a bad choice as well. Which is why I've repeatedly suggested a different keyword, and AFAIK you still haven't actually voiced an opinion on that. >If we define the rule spawn function_call, then >spawn acts as a prefix >in this expression. However, everything that is already defined for >function_call in PHP must remain valid. Yep, I'm totally fine with that. But you kept referring to that token as "expression", which confused me, because that's a different thing in the grammar. >The second form of the spawn expression is: >```php >spawn inline_function >``` This part totally makes sense from a syntax point of view, I just think it has bad usability - the user has to type a bunch more boilerplate, which looks like something it's not. >> If it's going to be a special case for an "inline coroutine", just use a >keyword other than "function", so it doesn't look like an expression when >it's not, like "spawn block { ... }"; or no keyword at all, just "spawn { >... }" >> > >Well, yes, but here we again face the issue with returnType >syntax, which >ends up hanging in the air... I think I asked this before: why would anyone want to specify a return type there? I assumed the actual user scenario we're trying to solve is "I have a bunch of statements I want to run in a new Coroutine, but they're not worth putting in a function". So to the user, having all the features of a function isn't relevant. We don't allow specifying the return type of a match statement, for example. Do you have a different scenario in mind? Rowan Tommins [IMSoP]