Native FFI: function-pointer (callback) parameters are unsupported, making callback-driven libraries unbindable

[DemonGPT]

Summary

scriptc's FFI manifest binds signature-only declarations to C ABI calls, but it provides no way to pass a C function pointer to a native symbol. Any library API that takes a callback becomes unbindable: it must either be removed or replaced with a polling workaround.
(I'm aware the Native FFI guide lists callbacks as not-yet-supported — filing this to capture the concrete API impact and the demand.)

Why this matters

Callbacks aren't an edge case in the C ecosystem — they're the primary integration point of most real libraries (SDL, FFmpeg, libcurl, GTK, libgit2, …). Event-driven, game, and UI frameworks are callback-shaped by design, and an FFI that can't pass function pointers leaves those libraries largely unusable. Concretely:

• Synchronous callbacks can't be worked around at all. Event filters must return a bool in-place; polling can't express that.
• The workaround is per-API and invasive. A timer/log-output workaround means writing a C trampoline + mutex-protected ring buffer + main-loop drain for each API — the bound surface degrades, and reverting it later is a large change.
• Native-thread callbacks need careful synchronization. Timers, audio, and I/O callbacks fire off the main thread, ruling out high-frequency or latency-sensitive callbacks.

Suggested direction (for discussion)

• A function-pointer FFI parameter that lowers to a registered C trampoline + a TS closure, with an explicit ownership/lifetime contract (e.g. a userdata handle passed back on invocation, GC pinning while registered, and an unregister call).
• A story for callbacks invoked from native threads — either documented invocation on the calling thread or marshalling onto the main loop.

[ctate]

Added additional support in #128. Let me know if this unblocks you, or if there's something else you need

[DemonGPT]

Thanks for the quick follow-up! I evaluated the call-scoped callback support from #128 (scriptc 0.0.26) against the callback-based APIs we're trying to bind, and unfortunately it doesn't unblock our case yet. Here's exactly where we're still stuck.
The call-scoped contract covers callbacks that fit the "visit/transform during the call" pattern:

int walk(list_t *list, int (*visit)(int item, void *ctx), void *ctx); // works

But the APIs we need don't fit that shape. They fall into three gaps:

1. Retained callbacks. The library stores the function pointer and invokes it later, after the registering call has returned:

void timer_add(uint32_t interval, void (*tick)(void *ctx), void *ctx);
void log_set(void (*emit)(int level, const char *msg, void *ctx), void *ctx);
void hint_add_watch(const char *name, void (*changed)(void *ctx), void *ctx);

lifetime: "call" rejects these, and there's no registration/unregistration ownership model to express them yet.
2. Foreign-thread invocation. Several of these callbacks fire on library-owned threads — timer threads, audio callbacks, worker/thread entry functions, async completion callbacks — often long after the registering call returned. Same-thread-only rules them all out.
3. Pointer/string callback parameters. Callback parameter lists currently accept only scalars (f64/bool/u8/u32/i32), but several callbacks need to receive a struct pointer or a NUL-terminated string from native code:

bool event_filter(void *ctx, const event_t *event);    // needs event pointer
void prop_visit(void *ctx, int id, const char *name);  // needs string

Even the call-scoped APIs we could use are blocked by the pointer parameters.
Concretely, these patterns are all still unexpressible in a manifest: registering a timer/log/hint/watch callback that fires later, passing a thread entry function, passing a callback that receives a pointer or string argument, and any callback that fires off the thread that registered it.
What would unblock us:

• a retained lifetime with an explicit unregister call and a defined ownership contract for the captured closure,
• foreign-thread invocation — either allowed-and-documented (callable from any thread) or marshalled to the main thread,
• pointer/string parameters in callback signatures (or a length-delimited copy of the value delivered to the callback).

[ctate]

@DemonGPT Thanks for providing more details. Much of this has been added in v0.0.33. Please try it out and lmk if it helps!