In what retroactively appears weird, I've implemented thread creation to take an FnMut rather than an Fn.
No clue why, though -- fixing it will be a breaking change, but should otherwise be straightforward.
I'm holding it for the next round of breaking changes, which given #37 could be quite soon.
(Maybe we'll fix threads returning values at the same time; there there will be questions like "do we need awaitability all the time when we return values"; the question is probably yes, and they'd get a different launch API).
Might also solve #23 while at it -- tracked threads are not a thing, they would just be owned threads (where the ownership token may contain a lifetime when started in a scope).
In what retroactively appears weird, I've implemented thread creation to take an FnMut rather than an Fn.
No clue why, though -- fixing it will be a breaking change, but should otherwise be straightforward.
I'm holding it for the next round of breaking changes, which given #37 could be quite soon.
(Maybe we'll fix threads returning values at the same time; there there will be questions like "do we need awaitability all the time when we return values"; the question is probably yes, and they'd get a different launch API).