On Thu, Oct 23, 2025, at 13:08, Edmond Dantes wrote:
> Hello.
>
> It seems to me that the following solution balances the different
> viewpoints better:
>
> 1. Keep the base Awaitable interface, which defines an object that
> can be awaited.
> 2. Introduce a FutureLike interface that extends Awaitable.
> 3. Modify the await() function so that it only accepts FutureLike
> objects.
> 4. Functions such as awaitAll or awaitAny may need to be renamed,
> but that’s outside the scope of this RFC.
> 5. There will be no need to create a Future for functions designed
> to work with an Awaitable object — this keeps the select case
> syntax clean.
>
> **Naming issue**
>
> I see a certain inconsistency between await and Awaitable.
> It might be worth coming up with a better name for Awaitable.
> I remember that “Observable” was once suggested.
>
Why not keep the name Awaitable instead of creating a FutureLike, but just harden the interface? We
can always loosen the interface in the future, or create a new interface for "streaming"
awaitables (aka, multi-shot Awaitable). Then await() could change its signature from
Async\await(Awaitable $awaitable): mixed to Async\await(Awaitable|StreamingAwaitable $awaitable) at
some point in the future -- and it would be BC.
— Rob