Hello.
In this email, I will focus only on the syntax because it is a separate and
rather complex topic.
First, the RFC does not clearly describe the syntax, which needs to be
fixed.
Second, you are right that methods and operators cause confusion.
However, I really liked the `$scope->spawn()` construct in the example
code, as it feels the most natural compared to `spawn in`.
Moreover, the `spawn in` expression is quite complex to implement, but I
don't have enough experience to evaluate it properly.
## Defer
I have nothing against the `suspend` keyword.
However, the `defer` keyword raises some questions. "Defer" means to
postpone something (to delay execution).
But in this case, it’s not about "postponing" but rather "executing upon
function block exit."
I don't know why the creators of Go chose this word. I considered
`finally`, but it is already used in the `try` block.
The implementation also concerns me a bit.
It seems that to fully implement the `defer` block, we would need something
similar to `finally`, or essentially make `defer` create an implicit
`try...finally` block.
## Spawn Operator
Yes, the chosen syntax has some ambiguity because there are two versions.
However, I didn't like the other options, mainly due to their verbosity.
**General syntax:**
```php
spawn [in <scope>] function [use(<parameters>)][: <returnType>] {
<codeBlock>
};
```
where:
- `parameters` - a list of parameters passed to the closure.
- `returnType` - the return type of the closure.
- `codeBlock` - the body of the closure.
Examples:
```php
spawn function {
echo "Hello";
};
spawn function:string|bool {
return file_get_contents('file.txt');
};
// Incorrect syntax
spawn {
echo "Test\n";
};
```
##### In scope expression
The `in` keyword allows specifying the scope in which the coroutine.
```php
$scope = new Async\Scope();
$coroutine = spawn in $scope function:string {
return "Hello, World!";
};
function test(): string {
return "Hello, World!";
}
spawn in $scope test();
```
The `scope` expression can be:
- A variable
```php
spawn in $scope function:void {
echo "Hello, World!";
};
```
- The result of a method or function call
```php
spawn in $this->scope $this->method();
spawn in $this->getScope() $this->method();
```
The form `spawn <callable>(<parameters>);`
is a shorthand for `spawn use(<callable>, <parameters>) { return ... };`
The expression `<callable>(<parameters>);` is not executed directly at
the point where `spawn` is used but in a different context.
There is a slight logical ambiguity in this form, but it does not seem
to cause any issues with comprehension.
As for the form:
`spawn (<expression>)(parameters)` — I suggest not implementing it at all.
It makes the code unreadable, and carries no meaningful advantage.
Saving a single variable only to get lost in parentheses? It's not worth it. :)
### Spawn Form
The form `spawn <callable>(<parameters>);`
is a shorthand for:
```php
spawn use(<callable>, <parameters>) { return ... };
```
The expression `<callable>(<parameters>);` is not executed directly at
the point where `spawn` is used but in a different context.
There is a slight logical ambiguity in this form, but it does not seem
to cause any issues with comprehension.
As for the form:
```php
spawn (<expression>)(parameters);
```
I suggest not implementing it at all.
It is simply terrible, makes the code unreadable, and carries no
meaningful advantage.
Saving a single variable only to get lost in parentheses? It's not worth it. :)
### Why do I use the `function` keyword in the second form?
Only to allow defining the return type.
In principle, both forms are equivalent:
```php
spawn {};
spawn function {};
```
I also like the `function` keyword because it unambiguously indicates
that this is not just a block of code but specifically a closure.
What I don’t like:
This form might complicate semantic analysis since now there are two
types of closures to parse.
Intuitively, it would be good to define it like this:
```php
spawn function() use() {};
```
— meaning to literally mirror the standard closure definition.
This way, an existing analysis block could be reused.
But what should we do with parameters? :)
In other words, I would prefer this aspect to be reviewed by someone
who is equally well-versed in the implementation.
---
Ed.
