> In terms of the grammar, it is a special case of #1 yes. > This example maybe helps explain why this might be surprising: > spawn $action;
Aha, so if I can write `spawn closure`, why can't I do the same with a variable? Yes, this creates an inconsistency. that's to be expected since the parentheses were removed. > > This feels like a stretch to me > >From the perspective of how responsibility is distributed in the code, this would be correct. But it has nothing to do with syntax consistency. > > From the user's point of view, it might be just as obvious that the closure put into a variable two lines above can also be called with zero arguments. > It's only as unclear as any other code involving a variable - if it's badly named and defined 100 lines away, > you'll have a problem, but no syntax can solve that. > That's correct. But I'm not sure it's that destructive in practice. > > I tried to make clear that the keywords could stand in for anything Yes, you want to keep the concise syntax while eliminating ambiguity with the variable. > > Specifically, what is the use case where syntax #2, "spawn function_call" is not good enough, leading us to add a special case into the grammar. > Additional parentheses around + parentheses after. That is, (closure)(). The goal is to get rid of this construct. > > Will it? By who, when? Honest question, and comes back to my point about identifying the use case. > Honest answer: I can't say for sure. I can assume that closures help define a small sub-area within a piece of code that performs a specific task. How common is this situation in the context of coroutines? Maybe not that much. A safer approach would be to implement only syntax 2 and consider the alternative option only if user feedback suggests it's needed. Sounds like a solution without drawbacks... > If return values end up somewhere, I don't think it would be hard to come up with examples that were slightly more than one function call, but still fit in a single-expression closure. like: ```php spawn fn() => [file_get_content(), file_get_content(), file_get_content()] ``` At this point, I haven't been able to come up with examples where such a closure would actually be convenient. Maybe this use case will emerge later.
