It should be working for bindings fine and ideally if we could support async/await from C# with it, would be great.

It should also provide an easier to use interface for Eina_Value as it will be heavily used by our data model and view. Maybe the possibility to have helper that will automatically take care of setting up the Eina_Value like :

efl_promise_double_set(promise, 0.0);
efl_promise_bool_set(promise, EINA_TRUE);

And on the other side a way to register type safe callback using inline code like (As future require manual binding anyway, we can add some nice infrastructure there) :

static void then_success_bool(void *data, const Efl_Event *ev, bool value);

SafePointer

You don't need safepointer... actually given the amount of usage of promise/future in Efl once it's deployed (jobs, timers, idlers...) we should be using mempool, then we can use a mempool property to safety-check based on that. Like you always allocate multiple of pagesize() blocks, keep a list of blocks. Upon API entry, check if the pointer is inside one block. If so, check if the slot is alive.

This would give safety and performance at the same time. Let's remember both Promise and Future are short lived and you're not calling many methods on them! Most of the methods you call is to invalidate it! Like fulfilling or error a promise; canceling a future.

Naming

Please stick to fulfill and error (or fail), if you go with efl_promise_XXX_set(), it looks like you can later set it again... which is not the case. Both fulfill or error will invalidate the promise once it returns.

Wait

This will break hell... let's not get into this, if we wait we not only create bad practice we may run into situations where we'd need to run the main loop, which could generate other events... inner main loops are always an issue.

• I guess we can indeed have a fast check for if a pointer belong to a mempool. Didn't think about this. Ok will go with that.

• So going with efl_promise_XXX_fulfill for all the helpers ?

• Wait ? What ? Ah, no, this is related to C#, not C. I am wondering how C# environment do implement this behavior and how we can deal with it. They looks like a coroutine, but not so sure. It is important to look at it as this is how MVVM is implemented in C#. We may have to find a way to connect C# Model with EFL View. This is at this point an investigation point, but definitively, not something to ditch.

yes, efl_promise_fulfill(Promise, Eina_Value) and variants like efl_promise_fulfill_bool(Promise, Bool)

need to check what's C# expectation, on our side, unless the promise is being executed on another thread, I don't see any way to "wait" unless we execute the main loop.

If we're the view, I don't see why we'd need a "wait" to connect to C# model... we'd be using the async patterns. The other way around could be problematic.