Reconsidering the semantics of Get in the Future Interface

[zaataylor]

The Future interface has only one behavior, which is to return a value if it's been set, and to block otherwise:

package workflow

type Future[T any] interface {
	// Get returns the value if set, blocks otherwise
	Get(ctx Context) (T, error)
}

Calls to execute activities (workflow.ExecuteActivity), schedule timers (workflow.ScheduleTimer), and create subworkflows workflow.CreateSubWorkflowInstance (among others) return Futures which users often block on in order to obtain a usable value, or handle errors if they occur.

While Get(ctx) works to illustrate what action the Future[T] is performing, a semantics which makes it more clear what action library users perform before a Future[T] returns could be more intuitive. With this in mind, I'm curious if Wait(ctx) might be a fitting, usability-enhancing alternative to Get(ctx)?

i.e.

package workflow

type Future[T any] interface {
	// Wait blocks until a value is set, then returns it
	Wait(ctx Context) (T, error)
}

[cschleiden]

That's a bit difficult. Get doesn't always wait. Consider something like this:

var f Future[int] // = get it from somewhere.

f.Get() // <- this will block
f.Get() // <- this will not

.Wait() might be more explicit in the first case but not quite accurate in the second case.

Other languages like C++ have tried to address this by having both an explicit .wait() and a .get(), although get also blocks if the value isn't available yet.

For now I'm not planning to change the interface.