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.