>
> Again, that's the *how*, not the *why*. We only need to "get rid of" the
parentheses if there's some reason to type them in the first place.
>
I’ve already understood that. You mean it’s not the reason, but one of the
possible solutions.
But it’s one of the solutions that, from my point of view, causes less
surprise.
Because the alternatives like `spawn fn` and `spawn {}` seem more radical
to me compared to the current design.
In that case, perhaps `spawn_fn` or `spawn closure` would be better options.
>
> spawn ( fn() => do_something( fetch_something($input) ) )();
Now this option, I’d say, looks realistic.
> spawn => do_something( fetch_something($input) ) );
Looks good. But then, of course, it turns out that spawn plays two roles —
including defining a closure in the language. That specific point is what
makes me doubt it.
It's like the language has TWO keywords for creating a closure.
Essentially, no matter how you approach it, some compromise will have to be
made.
* Either accept potential confusion between a variable and a `function`,
* Or agree that a closure will have two forms, and everyone will have to
learn them.
If we go with the second option, then we can use both forms:
```php
spawn use {};
spawn => code;
```
>
> Again, though, this could easily be added later when a need becomes
> visible, as long as we don't do something weird now that closes the door
> on it.
>
I tend to agree. If there's doubt, it's better to postpone it.
> spawn => $input |> fetch_something(...) |> do_something(...);
It can be made even cleaner by adding a parallelism operator.
That way, there’s no need to write `spawn` at all.
>
> I suggest we leave this sub-thread here; there's plenty of other things
to discuss. :)
>
Ok!
