The conversation has drifted a little from generics, I've replied inline
below:
On Wed, 2 Dec 2020 at 20:56, roger peppe <rogpe...@gmail.com> wrote:
> On Wed, 2 Dec 2020 at 09:15, roger peppe <rogpe...@gmail.com> wrote:
>
>> Also your delayed blocks don't wait for the preceding set of futures to
>>> be exhausted before proceeding, I think they're all triggered once the
>>> initial set is completed
>>
>>
>> Each delayed block is triggered when its associated delay has elapsed.
>> Once the initial set is completed, it returns immediately. Isn't that what
>> you want? As I said, I'm finding it hard to imagine a scenario where these
>> particular semantics are useful, so it's not easy to decide how to treat
>> the edge cases.
>>
> Specifically if there are no pending futures at a given instant, those in
the block of delayed futures next due are "unlocked". AsCompletedDelayed is
designed to allow prioritizing some futures over others, with timeouts
occurring if those that shouldn't be delayed anymore haven't returned in a
reasonable time (the next block are unlocked and can compete with the
higher priority ones).
> I'm talking rubbish there, I'm afraid. It's entirely possible to do this,
> albeit at the cost of an extra goroutine:
>
> func Map[A, B any](f *F[A], fn func(A) B) *F[B] {
> return Start(func() (B, error) {
> a, err := f.Result()
> if err != nil {
> return *new(B), err
> }
> return fn(a), nil
> })
> }
>
This is a great observation, thanks.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAB4yi1OGANBsoDLbouoG2XfA4R3ZPYmcn_MpBtX6N%2B38N2n4xA%40mail.gmail.com.
