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.