Hello.

Just one quick question for now; why is suspend() a function and not a
statement?

Yes, suspend() is a function from the Async namespace.
I couldn't find any strong reasons to define it as an operator:

suspend();
// vs
suspend;

For example, the spawn operator makes the code more expressive and
eliminates the need for closing parentheses. await here looks more like a
prefix for spawn.

Ed.

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:

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:

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.

$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

spawn in $scope function:void {
    echo "Hello, World!";
};

• The result of a method or function call

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:

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 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:

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:

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.

BoundedScope

I tried to refine the BoundedScope class to its logical completeness,
considering your feedback.
However, I no longer like it because it now resembles an advanced
ComposeFuture or BoundedFuture (I'm not even sure which one).

There is no doubt that such functionality is needed, but I have concerns
about the design.
It seems better to implement BoundedFuture separately (placing it in a
dedicated RFC) and incorporate this logic there, while BoundedScope might
not be necessary at all.

Essentially, the code using BoundedScope could be replaced with:

$scope = new Scope();
$future = BoundedFuture();
try {
     await $future;
} finally {
    $scope->dispose();
}

On the other hand, a method like spawnAndProlong could be useful if there
is a need to implement a pattern where the Scope remains alive as long as
at least one task is active.

But is this case significant enough to keep it? I'm not sure.

I need some time to process this.
In the meantime, I'll show you the draft I came up with.

BoundedScope

The BoundedScope class is designed to create explicit constraints
that will be applied to all coroutines spawned within the specified Scope.

The BoundedScope class implements the following pattern:

$scope = new Scope();

$constraints = new Future();

$scope->spawn(function () use($constraints) {

    try {
        await $constraints;
    } finally {
        \Async\currentScope()->cancel();
    }
});

Here, $constraints is an object implementing the Awaitable interface.
Once it completes, the Scope will be terminated, and all associated
resources will be released.

| Method | Description

     |

|----------------------------------------|-------------------------------------------------------------------------------------------------------------|
| defineTimeout(int $milliseconds) | Define a specified timeout,
automatically canceling coroutines when the time expires.
|
| spawnAndBound(callable $coroutine) | Spawns a coroutine and
restricts the lifetime of the entire Scope to match the coroutine’s
lifetime. |
| spawnAndProlong(callable $coroutine) | Spawns a coroutine and
extends the lifetime of the entire Scope to match the coroutine’s
lifetime. |
| boundedBy(Awaitable $constraint) | Limits the scope’s lifetime
based on a Cancellation token, Future, or another coroutine's
lifetime. |
| prolongedBy(Awaitable $constraint) | Extends the scope’s
lifetime based on a Cancellation token, Future, or another
coroutine's lifetime. |

$scope = new BoundedScope();
$scope->defineTimeout(1000);

$scope->spawnAndBound(function() {
    sleep(2);
    echo "Task 1\n";
});

await $scope;

Prolong and Bound triggers

The BoundedScope class operates with two types of triggers:

• Bound trigger – limits execution time by the minimum boundary.
• Prolong trigger – limits execution time by the maximum boundary.

For the Prolong trigger to execute, all Prolong objects must
be completed.
For the Bound trigger to execute, at least one Bound object
must be completed.

The Scope will terminate as soon as either the Prolong or
Bound trigger is executed.

defineTimeout

The defineTimeout method sets a global timeout for all coroutines
belonging to a Scope.
The method initializes a single internal timer, which starts when
defineTimeout is called.
When the timer expires, the Scope::cancel() method is invoked.

The defineTimeout method can only be called once; a repeated call
will throw an exception.

spawnAndBound / spawnAndProlong

spawnAndBound creates a coroutine and limits its execution time to
the current Scope.
The method can be called multiple times. In this case, the Scope
will not exist longer than
the lifetime of the shortest coroutine.

spawnAndProlong creates a coroutine and extends the lifetime of the
current Scope
to match the coroutine's lifetime.

boundedBy / prolongedBy

The boundedBy method allows limiting the lifetime of a Scope by explicitly
specifying an object that implements the Awaitable interface.

The Awaitable interface is inherited by classes such as Coroutine
and Scope.
Additionally, classes like Future and Cancellation,
which are not part of this RFC, can also implement the Awaitable interface.

Hello, Larry.

First off, it desperately needs an "executive summary" section up at the
top.
There's a lot going on, and having a big-picture overview would help a
ton. (For
examples, see property hooks[1] and pattern matching[2].)

I looked at the examples you provided, but I still don't understand what
exactly I could put in this section.
Key usage examples without explanation?
Do you think that would make the RFC better? I don’t really understand how.

Second, please include realistic examples. Nearly all of the examples are
contrived,

Which examples do you consider contrived, and why?

The first non-foobar example includes a comment "of course you should
never do it like this", which makes the example rather useless

Do you mean working with a closure that captures a reference to $this?
But that has nothing to do with this RFC, either directly or indirectly.
And it’s not relevant to the purpose of the example.

And the second is
built around a code model that I would never, ever accept into a code
base, so it's
again unhelpful.

Why?

So would the functions/keywords be shortcuts for
some of the common functionality of a Scope object?

Were you confused by the fact that the Scope object has a spawn method?
(Which is semantically close to the operator?)
I understand that having both a method and an operator can create
ambiguity, but it's quite surprising that it could be so confusing.

The first few sections of the RFC seem to read as "this RFC doesn't
actually
work at all, until some future RFC handles this other part."

How should I have written about this? It's simply a part of reality as it
is. Why did this cause confusion?
Yes, I split this RFC into several parts because it's the only way to
decompose it.
It’s logical that this needs to be mentioned so that those who haven’t
followed the discussion can have the right understanding.
What’s wrong with that?

Especially the BoundedScope. I see no reason for it to be separate from
just any other
Scope. What is the difference between scope and context? I have no clue.

Agreed, this needs to be clarified.

Are those
standard terms you're borrowing from elsewhere, or your own creation?

Unfortunately, I couldn't find terminology that describes these models.
However, the RFC itself provides definitions. What is confusing to you?

I cannot really tell which one the "playpen" model
would fit into.

If we're talking about the "nursery" model in Python, there is no direct
analogy because a nursery is not a coroutine, but rather a Scope in
this RFC.

In this context, the model in the RFC is essentially no different from
nurseries in Python.

The key difference lies elsewhere.
To define the structure, two elements are used:

• The coroutine itself
• An object of type Nursery or Scope

So in Python, coroutines work exactly the same way as in Go, and the
nursery is an additional mechanism to ensure structured concurrency.

In this RFC, there is a nursery (Scope), but in addition to that, coroutines
themselves are also part of the structure.
(So this RFC uses a stricter approach than Python)

Does this mean it's not clear from the text?

As an aside: I used "spawn" as a throw-away keyword to avoid using
"await" in a previous example. It's probably not the right word to use in
most of these cases.

If the verb spawn implies that "the code throws something overboard and
doesn't care about it," then it's not suitable. Other neutral alternatives
could be go or launch or start.
"start" sounds good.

So any
proposal should include copious examples of how those three cases would
look, and why
they're sufficiently ergonomic.

Thank you, I will add these cases to the examples.

I honestly cannot see a use case at this point for starting coroutines in
arbitrary scopes.

If we're talking about launching a coroutine in GlobalScope, then it's
99% likely to be an anti-pattern, and it might be worth removing
entirely. It's the same as creating a global variable using $GLOBAL[].

However, if we're referring to a pattern where a service defines its own
$scope, then this is probably one of the most useful aspects of this RFC.

Elsewhere in the thread, Tim noted that
we should unify the function call vs closure question.

It would be great if this were possible, but so far, I haven't found a
syntax that satisfies both requirements.

Of course, the syntax could be unified like this:

spawn function($params): string use() {
}('param');

and

function test($x);
spawn test($x);

But it looks unnatural...

Right now, I'm mentally close to the approach that Rowan_Tommins also
described.:

spawn use($parameters): string {};
spawn test($x);

Ed.

My biggest issue, though, is that I honestly can't tell what the mental model is supposed to be. The RFC goes into detail about three different async models. Are those standard terms you're borrowing from elsewhere, or your own creation? If the former, please include citations. I cannot really tell which one the "playpen" model would fit into. I... think bottom up, but I'm not sure. Moreover, I then cannot tell which of those models is in use in the RFC. There's a passing reference to it being bottom up, I think, but it certainly looks like the No Limit model. There's a section called structured concurrency, but what it describes doesn't look a thing like the playpen-definition of structured concurrency, which as noted is my preference. It's not clear why the various positives and negatives are there; it's just presented as though self-evident. Why does bottom up lead to high memory usage, for instance? That's not clear to me. So really... I have no idea how to think about any of it.

I had a very different reaction to that section. I do agree that some citations and links to prior art would be good - I mentioned in my first email that the "actor model" is mentioned in passing without ever being defined - but in general, I thought this summary was very succinct:

• No limitation. Coroutines are not limited in their lifetime and run as long as needed.
• Top-down limitation: Parent coroutines limit the lifetime of their children
• Bottom-up limitation: Child coroutines extend the execution time of their parents

Since you've described playpens as having an implicit "await all", they're bottom-up: the parent lasts as long as its longest child. Top-down would be the same thing, but with an implicit "cancel all" instead.

Broadly speaking, I can think of three usage patterns for async in PHP (speaking, again, as someone who doesn't have a lot of async experience, so I may be missing some):

1. Fan-out. This is the "fetch all these URLs at once" type use case, which in most cases could be wrapped up into a para_map() function. (Which is exactly what Rust does.)
2. Request handlers, for persistent-process servers. Would also apply for a queue worker.
3. Throw it over the wall. This would be the logging example, or sending an email on some trigger, etc. Importantly, these are cases where there is no result needed from the sub-routine.

I agree that using these as key examples would be good.

// Creates an async scope, in which you can create coroutines.
async {

The problem with using examples like this is that it's not clear what happens further down the stack - are you not allowed to spawn/start/whatever anything? Does it get started in the "inherited" scope?

You've also done exactly what you complained the RFC did and provided a completely artificial example - which of the key use cases you identified is this version of scope trying to solve?

I actually think what you're describing is very similar to the RFC, just with different syntax; but your examples are different, so you're talking past each other a bit.

I honestly cannot see a use case at this point for starting coroutines in arbitrary scopes.

The way I picture it is mostly about choosing between creating a child within a narrow scope you've just opened, vs creating a sibling in the scope created somewhere up the stack.

The "request handler" use case could easily benefit from a "pseudo-global" scope for each request - i e. "tie this to the current request, but not to anything else that's started a scope in between".

There were also some concrete examples given in the previous thread of explicitly managing a context/scope/playpen in a library.

Rowan Tommins
[IMSoP]

If I say it's bright, you call it dark.
If I choose the east, you push for the south.
You’re not seeking a path, just a fight...
Debating with you? Not worth the time!

Em ter., 18 de mar. de 2025 às 03:00, Larry Garfield larry@garfieldtech.com
escreveu:

Good day, everyone. I hope you're doing well.

https://wiki.php.net/rfc/true_async

Here is a new version of the RFC dedicated to asynchrony.

Key differences from the previous version:

• The RFC is not based on Fiber; it introduces a separate class
  representation for the asynchronous context.

I'm unclear here. It doesn't expose Fibers at all, or it's not even
touching the C code for fibers internally? Like, would this render the
existing Fiber code entirely vestigial, not just its API?

• All low-level elements, including the Scheduler and Reactor, have
  been removed from the RFC.
• The RFC does not include Future, Channel, or any other primitives,
  except those directly related to the implementation of structured
  concurrency.

The new RFC proposes more significant changes than the previous one;
however, all of them are feasible for implementation.

I have also added PHP code examples to illustrate how it could look
within the API of this RFC.

I would like to make a few comments right away. In the end, the Kotlin
model lost, and the RFC includes an analysis of why this happened. The
model that won is based on the Actor approach, although, in reality,
there are no Actors, nor is there an assumption of implementing
encapsulated processes.

On an emotional level, the chosen model prevailed because it forces
developers to constantly think about how long coroutines will run and
what they should be synchronized with. This somewhat reminded me of
Rust’s approach to lifetime management.

Considering that lifetime management is one of the hardest things in Rust
to learn, that's not a ringing endorsement.

Another advantage I liked is that there is no need for complex syntax
like in Kotlin, nor do we have to create separate entities like
Supervisors and so on. Everything is achieved through a simple API that
is quite intuitive.

I'll be honest... intuitive is not the term I'd use. In fact, I didn't
make it all the way through the RFC before I got extremely confused about
how it all worked.

First off, it desperately needs an "executive summary" section up at the
top. There's a lot going on, and having a big-picture overview would
help a ton. (For examples, see property hooks[1] and pattern
matching[2].)

Second, please include realistic examples. Nearly all of the examples are
contrived, which doesn't help me see how I would actually use async
routines or what the common patterns would be, and I therefore cannot
evaluate how well the proposal treats those common cases. The first
non-foobar example includes a comment "of course you should never do it
like this", which makes the example rather useless. And the second is
built around a code model that I would never, ever accept into a code base,
so it's again unhelpful. Most of the RFC also uses examples that... have
no return values. So from reading the first half of it, I honestly
couldn't tell you how return values work, or if they're wrapped in a Future
or something.

Third, regarding syntax, I largely agree with Tim that keywords are better
than functions. This is very low-level functionality, so we can and should
build dedicated syntax to make it as robust and self-evident (and IDE
friendly) as possible.

That said, even allowing for the async or await or spawn keywords, I got
super confused when the Scope object was introduced. So would the
functions/keywords be shortcuts for some of the common functionality of a
Scope object? If not, what's the actual difference? I got lost at that
point.

The first few sections of the RFC seem to read as "this RFC doesn't
actually work at all, until some future RFC handles this other part."
Which... no, that's not how this works. :-)

As someone that has not built an async framework before (which is 99.9% of
PHP developers, including those on this list), I do not see the point of
half the functionality here. Especially the BoundedScope. I see no reason
for it to be separate from just any other Scope. What is the difference
between scope and context? I have no clue.

My biggest issue, though, is that I honestly can't tell what the mental
model is supposed to be. The RFC goes into detail about three different
async models. Are those standard terms you're borrowing from elsewhere, or
your own creation? If the former, please include citations. I cannot
really tell which one the "playpen" model would fit into. I... think
bottom up, but I'm not sure. Moreover, I then cannot tell which of those
models is in use in the RFC. There's a passing reference to it being
bottom up, I think, but it certainly looks like the No Limit model.
There's a section called structured concurrency, but what it describes
doesn't look a thing like the playpen-definition of structured concurrency,
which as noted is my preference. It's not clear why the various positives
and negatives are there; it's just presented as though self-evident. Why
does bottom up lead to high memory usage, for instance? That's not clear
to me. So really... I have no idea how to think about any of it.

Sorry, I'm just totally lost at this point.

As an aside: I used "spawn" as a throw-away keyword to avoid using "await"
in a previous example. It's probably not the right word to use in most of
these cases.

I know some have expressed the sentiment that tightly structured
concurrency is just us not trusting developers and babysitting them. To
which I say... YES! The overwhelming majority of PHP developers have no
experience writing async code. Their odds of getting it wrong and doing
something inadvertently stupid by accident through not understanding some
nuance are high. And I include myself in that. MY chances of
inadvertently doing something stupid by accident are high. I want a
design that doesn't let me shoot myself in the foot, or at least makes it
difficult to do. If that means I cannot do everything I want to... GOOD!
Humans are not to be trusted with manually coordinating parallelism. We're
just not very good at it, as a species.

Broadly speaking, I can think of three usage patterns for async in PHP
(speaking, again, as someone who doesn't have a lot of async experience, so
I may be missing some):

1. Fan-out. This is the "fetch all these URLs at once" type use case,
   which in most cases could be wrapped up into a para_map() function. (Which
   is exactly what Rust does.)
2. Request handlers, for persistent-process servers. Would also apply for
   a queue worker.
3. Throw it over the wall. This would be the logging example, or sending
   an email on some trigger, etc. Importantly, these are cases where there is
   no result needed from the sub-routine.

I feel like those three seem to capture most reasonable use cases, give or
take some details. (And, of course, many apps will include all three in
various places.) So any proposal should include copious examples of how
those three cases would look, and why they're sufficiently ergonomic.

A playpen model can handle both 1 and 2. In fan out, you want the "Wait
all" logic, but then you also need to think about a Future object or
similar. In a request handler, you're spawning an arbitrary number of
coroutines that will terminate, and you probably don't care if they have a
return value.

It's the "throw over the wall" cases where a playpen takes more work. As
I showed previously, it can be done. It just takes a bit more setup. But
if that is too much for folks, I offer a compromise position. Again, just
spitballing the syntax specifics:

// Creates an async scope, in which you can create coroutines.
async {

// Creates a new coroutine that MAY last beyond the scope of this block.
// However, it MUST be a void-return function, indicating that it's
going to
// do work that is not relevant to the rest of this block.
spawn func_call(1, 2, 3);

// Creates a new coroutine that will block at the end of this async
block.
// The return value is a future for whatever other_function() will
return.
// $future may be used as though it were the type returned, but trying
// to read it will block until the function completes. It may also have
other
// methods on it, not sure.
$future = start other_function(4, 5, 6);

// Queues a coroutine to get called after all "start"ed coroutines have
completed
// and this block is about to end. Its return value is discarded.
Perhaps it should be
// restricted to void-return, not sure. In this case it doesn't hurt
anything.
defer cleanup(7, 8, 9);

// Do nothing except allow other coroutines to switch in here if they
want.
suspend;

// Enqueues this coroutine to run in 100 ms, or slightly thereafter
whenever the scheduler gets to it.
timeout 100ms something(4, 5, 6);

} // There is an implicit wait-all here for anything start-ed, but not for
spawn-ed.

I honestly cannot see a use case at this point for starting coroutines in
arbitrary scopes. Only "current scope" and "global scope, let it escape."
That maps to "start" and "spawn" above. If internally "spawn" gets
translated to "start in the implicit async block that is the entire
application", so that those coroutines will still block the whole script
from terminating, that is not a detail most devs will care about. (Which
also means in the global async scope, spawn and start are basically
synonymous.)

I can see the need for cancellation, which means probably we do need a
scope object to represent the current async block. However, that's just a
cancel() method, which would propagate to any child. Scheduling it can be
handled by the timeout command. At this point, I do not see the use case
for anything more advanced than the above (except for channels, which as I
argued before could make spawn unnecessary). There may be a good reason
for it, but I don't know what it is and the RFC does not make a compelling
argument for why anything more is needed.

I could see an argument that async $scope { ... } lets you call all of the
above keywords as methods on $scope, and the keywords are essentially a
shorthand for "this method on the current scope". But you could also pass
the scope object around to places if you want to do dangerous things. I'm
not sure if I like that, honestly, but it seems like an option.

Elsewhere in the thread, Tim noted that we should unify the function call
vs closure question. I used straight function calls above for simplicity,
but standardizing on a closure also makes sense. Related, I've been
talking with Arnaud about trying to put Partial Function Application
forward again[3], assuming pipes[4] pass. If we follow the previous model,
then it would implicitly provide a way to turn any function call into a
delayed function call:

function foo(int $a, int $b) { ... }

foo(4, 5); // Calls foo() right now
foo(4, 5, ...); // Creates a 0-argument closure that will call foo(4, 5)
when invoked.

Basically the latter is equivalent to:
fn() => foo(4, 5);

A 0-argument closure (because all arguments are already captured) goes by
the delightful name "thunk" (as in the past tense of think, if you don't
know English very well.) That likely wouldn't be ideal, but it would make
standardizing start/spawn on "thou shalt provide a closure" fairly
straightforward, as any function could trivially be wrapped into one.

That's not necessarily the best way, but I mention it to show that there
are options available if we allow related features to support each other
synergistically, which I always encourage.

Like Tim, I applaud you're commitment to this topic and willingness to
work with feedback. But the RFC text is still a long way from a model that
I can wrap my head around, much less support.

[1] https://wiki.php.net/rfc/property-hooks
[2] https://wiki.php.net/rfc/pattern-matching
[3] https://wiki.php.net/rfc/partial_function_application
[4] https://wiki.php.net/rfc/pipe-operator-v3

--Larry Garfield

Continuing the discussion from [PHP-DEV] PHP True Async RFC - Stage 2:

[quote="Crell, post:16, topic:1573"]
// Creates an async scope, in which you can create coroutines.
[/quote]

Yes, I understand what this is about.
Here’s a more specific example: launching two coroutines and waiting for
both.

$scope = new Scope();
$scope->spawn(fn() => ...);
$scope->spawn(fn() => ...);

await $scope;

The downside of this code is that the programmer might forget to write
await $scope.
Additionally, they constantly need to write $scope->.

This code can be replaced with syntactic sugar:

async {
    spawn ...
    spawn ...
};

Am I understanding this correctly? Does it look nice? I think yes.
And at the same time, if the closing bracket is missing, the compiler will
throw an error, meaning you can't forget to await.

That is the only advantage of this approach.

Now, let's talk about the downsides.

function task(): void {
    spawn function() {
        echo "What?";
    };

    async {
        spawn ...
        spawn ...
    };
}

Let me explain.
You can write the spawn operator outside the async block. Why?

Because nothing can prevent you from doing so. It’s simply impossible.
After all, the function might already be executing inside another async
block outside its scope.

That’s exactly what happens an async block is essentially always present
as soon as index.php starts running.

It is necessary to determine whether this syntax truly provides enough
benefits compared to the direct implementation.

I will think about it.

Generally, RFCs are for changes in the language itself, not for API
contracts in C. That can generally be handled in PRs, if I understand
correctly.

I thought this was handled by PHP INTERNAL.
So I have no idea how it actually works.

or other weird shenanigans? I think it would be better as a statement.

Your example was absolutely convincing.
I have nothing to argue with :)
So, suspend is 100% an operator.

What happens if it throws? Why does it return NULL; why not void or
the result of the awaited spawn?

Exceptions are thrown if they exist. This also applies to suspend, by the
way.

Why not void?
Because the expression $result = await ... must resolve to something.

If I remember the core code correctly, the PHP engine returns NULL even
if the function is declared as void.

Wouldn't it be better to throw an exception instead of silently failing?

Possibly, yes.
For me, this is a difficult situation because the code inside the final
handler is already executing in a context where any exception can interrupt
it.

Hmm. Do you mean this literally? So if I call a random function via
spawn, it will have access to my current scope?

Exactly.
And yes, accessing a Scope defined in a different context is like
shooting yourself in the foot.
That's why this possibility should be removed.

I know I have been critical in this email, but I actually like it; for
the most part. I think there are still some rough edges to sand down and
polish, but it is on the right track!

In this RFC, I made two very big mistakes due to attention distortion.
This once again proves that it should be moved forward very slowly, as it
only seems simple.

The first major mistake was that I tried to make functions an element of
structural concurrency.
But to do so, functions would need to have an async attribute, which
contradicts the RFC.

The second mistake is the currentScope() function, which doesn't just
shoot you in the foot—it shoots you straight in the head (just like
globalScope()).
Of course, a programmer can intentionally pass the $scope object to
another coroutine, but making it easier for them to do so is madness.

await $some with 5s;

Maybe

await $some limit 5s;

Hello everyone,
I’d like to ask for your help regarding the syntax.

Goal: I want to get rid of the BoundedScope object while still
providing a convenient built-in tool for controlling wait time.

To achieve this, we could extend the await expression so that it allows
explicitly specifying a limit.
For example:

await $some with 5s;

Or a more general approach:

[<resultExp> = ] await <AwaitExp> [bounded <CancellationExp>];

I’m concerned that no other programming language has a similar construct.

On the other hand, if Cancellation is defined in a different way (not
through syntax), it requires a separate function. For example:

await all([$task1, $task2], $cancellation);

This approach is actually used in all other languages.

My question is: Should cancellation have its own syntax, or should we
follow the conventional approach?

--
Iliya Miroslavov Iliev
i.miroslavov@gmail.com

As I write more code examples, I'm starting to get annoyed by the verbosity of the spawn in $scope construct—especially in situations where all spawns need to happen within the same context.

At the same time, in 80% of cases, it turns out that explicitly defining $scope is the only correct approach to avoid shooting yourself in the foot.
So, it turns out that the spawn in $scope construct is used far more frequently than a plain spawn.

with async

function generateReport(): void
{
    try {
    
        $scope = Scope::inherit();
        
        async $scope {
            [$employees, $salaries, $workHours] = await Async\all([
                spawn fetchEmployees(),
                spawn fetchSalaries(),
                spawn fetchWorkHours()
            ]);
    
            foreach ($employees as $id => $employee) {
                $salary = $salaries[$id] ?? 'N/A';
                $hours = $workHours[$id] ?? 'N/A';
                echo "{$employee['name']}: salary = $salary, hours = $hours\n";
            }        
        }
        
    } catch (Exception $e) {
        echo "Failed to generate report: ", $e->getMessage(), "\n";
    }
}

async syntax

async <scope> {
    <codeBlock>
}

I can see how you think that syntactic sugar is understandably needed for spawn in scope, but again, you’re still writing code that makes no sense: why do you care about fetchEmployees (a possible library function) not spawning any fiber?

You already explicitly await all fibers spawned in the generateReport function, you get all the data you need, any extra spawned fibers should not interest you for the purpose of the logic of generateReport.

This is because again, the main use case listed of making sure all fibers are done after a request is a footgun is a non-business-logic requirement, an exercise in functional purity that also reduces caching and concurrency opportunities, as mentioned before.

A (somewhat bikesheeding, but this has been the vast majority of the posts on this thread anyway) note is that await could also be made to accept an iterable of futures, avoiding the use of Async\all combinators.

Regards,
Daniil Gentili.