Separate from #64 (no release API for Opaque values) - this is about the other end of the same lifecycle. opaque_make is async-only, with no sync twin the way closure_call_sync exists for closures. That means any module wanting to hand back a fresh opaque value from inside a function that's already running on the sync fast path has no real way to do it through the official API at all.
Ran into this directly in pix_n_flix (source-academy/modules#824): needed a function that returns something representing a specific pixel, callable from inside an already-sync-running filter. Ended up hand-packing the reference into a plain number and wrapping it as an OPAQUE value ourselves, deliberately never registering it through opaque_make, since going through the real async API would force the whole call back onto the slow path. Works, but it means the module owns validating these values entirely on its own rather than leaning on conductor's own bookkeeping at all.
Would be good to have an opaque_make equivalent that can actually be used from a .sync twin, for modules that want this without resorting to inventing their own encoding scheme.
Separate from #64 (no release API for Opaque values) - this is about the other end of the same lifecycle. opaque_make is async-only, with no sync twin the way closure_call_sync exists for closures. That means any module wanting to hand back a fresh opaque value from inside a function that's already running on the sync fast path has no real way to do it through the official API at all.
Ran into this directly in pix_n_flix (source-academy/modules#824): needed a function that returns something representing a specific pixel, callable from inside an already-sync-running filter. Ended up hand-packing the reference into a plain number and wrapping it as an OPAQUE value ourselves, deliberately never registering it through opaque_make, since going through the real async API would force the whole call back onto the slow path. Works, but it means the module owns validating these values entirely on its own rather than leaning on conductor's own bookkeeping at all.
Would be good to have an opaque_make equivalent that can actually be used from a .sync twin, for modules that want this without resorting to inventing their own encoding scheme.