This isn’t “real” call/cc; the “continuation” here must be suspended and then resumed exactly once. It’s intended for writing async wrappers for callback-based APIs that take a completion function.
Yeah. This change doesn’t really introduce a new capability per se; it just ties together some of the existing concurrency primitives that other folks are working on in a new way.
As a low-level primitive to be used with await, only compatible with async functions.
Which, if you think about it, is not as unusual as it sounds! In JavaScript, for instance, awaiting an object is equivalent to calling .then() on it, passing a closure which, when called, continues the function that awaited. In other words, JavaScript’s await is call/cc. It just uses .then() instead of a direct call, and has some extra complexity in the form of the ‘rejected’ callback. Other than that it’s the same thing.
Edit: Well, except for the part where you can’t call the resume function more than once (I think?). Which is apparently also the case with this Swift version.
i wish more languages provided call-cc. some languages let you freeze/restore a single stack frame, but it's unfashionable these days to freeze/restore an entire call chain. i find it to be a clean building block for all sorts of operations, like undo, multithreading, exception handling, etc. i missed this feature so much in python that i added it as a library [0].
Wouldn't it be safer to have a purpose-built state save and restore? This is a cool trick and will work in tightly controlled situations, but I wouldn't be comfortable using it with any third party library (so any non-trivial app) or if there's a chance of version update which changes state structure.
