Re: PHP True Async RFC - Stage 2

> > But even though we're talking in circles about why, > your latest examples do avoid the particular problem I was trying to describe. > I thought the problem was that the syntax wouldn't work. Is there any other issue? > > 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. > Does this concern the syntax of spawn block {} or did I miss something? I will describe the reasons why I rejected the concise syntax in favor of a more verbose one below. > > But you kept referring to that token as "expression", which confused me, because that's a different thing in the grammar. > By the word "expression," I mean a language construct along with keywords. If spawn function_call returns a value, then it can be considered an expression, right? Or am I mistaken in the terminology? > > I think I asked this before: why would anyone want to specify a return type there? > A simple answer (though not necessarily the correct one): because it’s a closure. And in PHP, a closure has a return type. I understand what you're asking: what is the practical significance of this? Perhaps none, but it provides consistency in syntax. The syntax spawn {}; is the most elegant in terms of brevity. There's no doubt that it's shorter by the number of characters in "function". - spawn block {}; also looks decent. However, the keyword block does not accurately reflect what is happening, because what follows is not a block but a closure. - spawn closure {}; is a possibility, but it raises the question: why introduce the keyword closure when we already have function? The difference in characters is minimal. - spawn fn {}; is the shortest option, but fn is already used for the shorthand function syntax fn() => .... But we can forget about ReturnType, right? Okay, but there's another point. In PHP, code blocks are not all the same. - if / then / else / try / switch **do not create a new scope**. - function **does create a new scope**. When a programmer writes: ```php $x = 5; spawn {$x++}; ``` Will they easily understand that $x++ is not modifying the same $x as before? No, they won’t. They will have to remember that spawn {} creates a closure, just like function creates a closure with a separate scope. This means the programmer has to remember one extra rule. The question is: is it worth the additional "function" characters? Though, I don’t mind spawn fn {};—this option takes the best of everything. But if we implement it, I would also introduce the fn() {} syntax. ``` spawn fn use($x) { ... }; ``` Apart from violating the language's style, I don't see any drawbacks for this.