On Wed, Oct 22, 2025, at 17:30, Edmond Dantes wrote:
> > This isn't even the same example. We're not talking about type juggling,
> > but an interface. Mixed is not an object nor an interface.
> Why?
> Type and Interface are contracts.
>
> > The "FutureLike" type is exactly what I'm arguing for!
>
> I have nothing against this interface. My point is different:
> 1. Should the await and awaitXX functions accept only Future?
> 2. Should Awaitable be hidden from the PHP userland?
>
> > foreach($next = await($awaitable)) { }
> What’s the problem here? The object will return a result.
> If the result is iterable, it will go into the foreach loop. An
> absolutely normal situation.
Assuming an awaitable is idempotent (such as the result of a coroutine), this
is an infinite loop. There’s a 99.9% chance that’s unintended, which is part of
the point of static analysis.
> > error: multiple usages of multi-shot Awaitable; you may get a different
> > result on each invocation of await()
> Why can’t you call await twice? What’s illegal about it?
> If it’s a Future, you’ll get the previous result; if it’s an
> Awaitable, you’ll get the second value.
> But the correctness of the code here 100% depends on the programmer’s intent.
There’s no world this would be intentional to get two separate values in two
separate places, especially concurrently, except in very rare circumstances.
You can’t guarantee ordering, and I can’t imagine wanting to interleave results
across multiple code paths. Well, I can, but that feels like a very brittle
system and a pita to maintain/debug.
>
> > The RFC doesn't spell this out and needs some work here.
> I don’t understand what exactly isn’t specified in the RFC?
>
> > When I say "violations" I mean that, assuming $a and $b resolve instantly:
> > awaitAll([$a, $b]) !== [await($a), await($b)]
> > ...
>
> This is a logical error. Сircular reasoning. The desired behavior is
> being used here as proof of the undesired one. (recursion)
> In the general case, these equations should not work — and that’s
> normal if the code expects entities that are not Future, but, for
> example, channels.
Ok. If it’s circular reasoning, then what’s the definition of awaitAll? How do
we explain it to junior devs, what guarantees can we make from it?
> > This is my mistake though. The discussion about await() is all mixed up
> > with coroutines so its hard to tell what the actual behaviour for await()
> > is outside of the context of coroutines.
> > The violation I thought of only applies to coroutines, the actual behaviour
> > is "undefined" in the RFC.
>
> `await()` does two things:
> 1. Puts the coroutine into a waiting state.
> 2. Wakes it up when the `Awaitable` object emits an event.
>
> `awaitAny` / `awaitAll` do the same but for a list of objects or an iterator.
The RFC says that for *coroutines, *but not *Awaitable.* It is undefined.
>
> However, the result of `await()` depends on the object being awaited.
> Thus, there are two separate contracts here:
> 1. **The waiting contract** — how the waiting occurs.
> 2. **The result contract** — how the result is obtained.
>
> From a language design perspective, there should be an explicit
> representation for these contracts.
> Something similar appeared only in Swift (e.g., `try await`).
>
> So, from the standpoint of “perfect design,” this is a simplification,
> which makes it not ideal.
>
> I can remove the `Awaitable` interface from the `RFC` and replace it
> with `FutureLike`. It costs nothing to do so.
> But before doing that, I want to be at least 95% sure that in 2–3
> years we won’t have to bring it back or add workarounds.
Bringing it back is much much much easier than taking it away.
>
> > It has everything to do with it! If a multi-shot Awaitable keeps emitting,
> > this causes repeated wakeups to the same continuation. It has to schedule
> > this every time and there isn't a way to say "don't > produce until
> > consumed". You can basically starve other tasks from executing. However, if
> > you use iterables of single-shot Awaitables, you get backpressure "for
> > free" and don't request the next
> > future until the previous one is complete, otherwise, the buffering
> > pressure lands in the awaitable (unbounded memory) or in the schedulers
> > ready queue (which affects fairness). Further, when
> > cancelling a multi-shot awaitable, should the scheduler drop pending
> > emissions and what happens if it keeps re-enqueing it anyway? It makes the
> > scheduler far more complicated than it needs to > be!
>
> If an Awaitable object isn’t being awaited, it can’t emit events, nor
> can it interfere with the scheduler.
> Unless the programmer explicitly creates new coroutines for every event by
> hand.
> If an Awaitable has a lot of data and wakes up 1000 coroutines, then
> the scheduler will ensure that all those coroutines get executed.
> But until these 1000 coroutines finish processing the data, the
> Awaitable cannot wake anyone else.
> So there is a natural limit to the number of subscribers. it can only
> be exceeded through explicitly incorrect handling of coroutines.
>
> Because the scheduler’s algorithm is extremely simple, it has little
> to no starvation issues.
> Starvation problems usually arise in schedulers that use more
> “intelligent” approaches.
You’re making some assumptions:
1. That the scheduler will always be cooperative.
2. That the scheduler you implemented as a proof-of-concept will be the one
shipped.
There’ll come a day where someone will want to write a preemptive coroutine
scheduler, or even a multi-threaded scheduler. That might be in 20–30 years, or
next year; we don’t know. But if they do, having Awaitables multi-shot *will*
prevent that from being a realistic PR. The amount of complexity required for
such an implementation would be huge.
>
> > A footgun is any reasonable looking code that subtly breaks because the
> > contract is weak, not because the programmer didn't RTFM.
> The code cannot be considered “reasonable,” because in this case the
> programmer is clearly violating the contract.
> And not because the contract is complex or confusing, but because they
> completely ignored it. This doesn’t look like a footgun.
>
At this point, we’re debating philosophy, but according to the RFC, coroutines
will be entirely safe to handle this way, but not ALL awaitables. *That’s what
makes it a footgun.* Sometimes, it’s reasonable, and it works ... and in
certain cases, it doesn’t work at all. Nobody can tell by simply reading the
code in a code review unless they had been shot in the foot before.
— Rob
