This is simply a wonderful explanation. I will be able to go through each
point.
But before that, let's recall what spawn essentially is.
Spawn is an operation that creates a separate execution context and then
calls a function within it.
To perform this, spawn requires two things:
1. **callable** – something that can be called; this is an expression or
the result of an expression.
2. **argument list** – a list of arguments.
>
> 1: keyword expr
>
Then, this construct is a special case of another one:
`keyword expr argument_list`
However, PHP already has an expression that includes `expr
argument_list`—this is `function_call`.
Therefore, the `keyword function_call` variant is inherently a valid and
complete form that covers all possible cases.
So in the general case, `keyword expr` does not have a meaningful
interpretation and does not necessarily need to be considered, especially
if it leads to a contradiction.
In other words:
Option #1 is a special case.
Option #2 is the general case.
So, Option #2 should be our Option #1 because it describes everything.
>
> 3: keyword expr_except_function_call
>
If this expression is intended to call a closure, then essentially it is
almost the same as #1.
That means all our conclusions about #1 also apply to this option.
>
> 4: keyword inline_function
>
This option can be considered a special case of option #2. And that’s
exactly the case.
>
> This is less confusing, but has one surprising effect: if you refactor
the inline function to be a variable, you have to replace it with "$foo()"
not just "$foo", so that you hit rule #2
>
A completely logical transformation that does not contradict anything. If I
want to use a variable, this means:
1. I want to define a closure at point A.
2. I want to use it at point B.
3. Point A does not know where point B is.
4. Point B does not know what arguments A will have.
5. Therefore, I need to define a list of arguments to explicitly state
what I want to do.
The meaning of option #4 is different:
1. I want to define a closure at point A.
2. I want to use it at point A.
3. Point A knows what the closure looks like, so there is no need to
define arguments — it's the same place in the code.
Therefore, the `keyword closure` does not break the clarity of the
description, whereas the `keyword $something` does.
>
> 5: keyword_foo expr
>
The same #1.
>
> 6: keyword_bar function_call
>
This contains even more characters than the original and yet adds nothing
useful.
>
> 7. 7: keyword '{' inner_statement_list '}'
>
let me add another nail to the coffin of this option:
```php
class Some {
public function someMethod()
{
spawn static function() {
...
}
}
}
```
Another point in favor of option #4 is the `static` keyword, which is also
part of the closure.
>
> But I do want to come back to the question I asked in my last e-mail:
what is the use case we're trying to cater for?
>
Goal #1: Improve code readability. Make it easier to understand.
Goal #2: Reduce the number of characters.
The `spawn` keyword simplifies constructs by removing two parentheses and
commas. For example:
```php
spawn file_get_content("file");
vs
spawn("file_get_content", "file");
```
The first option looks as natural as possible, and spawn is perceived as a
prefix. And that’s exactly what it is — it essentially works like a prefix
operation.
In other words, its appearance reflects its behavior, assuming, of course,
that we are used to reading from left to right.
>
> If the aim is "a concise way to wrap a few statements", we've already failed
if the user's writing out "function" and a "use" clause.
>
Yes, but the `function ... use` syntax was not invented by us. We can't
blame ourselves for something we didn't create. :)
If closures in PHP were more concise, then `spawn + closure` would also
look shorter.
We cannot take responsibility for this part.
>
> If the aim is "a readable way to use a closure", rule #2 is fine.
>
Great. All that's left is to approve option #4 :)
>
> but it's probably more readable to assign the closure to a temporary
variable anyway
>
In this case, we increase the verbosity of the code and force the
programmer to create an unnecessary variable (not good).
The advantage of option #4 is not just that it removes parentheses, but
also that it keeps the code readable.
It's the same as `(new Class(...))->method()` — the point is not about
saving keystrokes (after all, nowadays ChatGPT writes the code anyway), but
about the level of readability. It improves readability by about 1.5 times.
That's the key achievement.
The second reason why option #4 makes sense: it will be used frequently.
And that means the programmer will often create unnecessary variables.
Do you really want that?
For example, `spawn fn() => file_get_content()` won’t be, because it
doesn’t make sense.
