dyn safety and fn pointers:
There are no place for state, produced by asynchrony or multiplicity in case of fn pointers => cannot allow.
Thereof, fn pointers only can have non local returns.
In case of explicit boxed dyn Trait
, we allow Fn
trait to accept only non local return effect (it does not mutate anything); FnMut
is allowed to have rest of effects as long as their state is Unpin
. AFAIK boxed things have stable location in memory even in face of allocators API, Unpin
here is actually not necessary.
This is also the case for a representation of labels:
The destructors should be run before returning (setting the value, then jumping).
The information passed in the second repr. is indeed insufficient, my bad, but... - what if we do it like that:
(
*const fn(*mut ResumeTy), /*a callback for setting where to place resume arg*/
(
*mut YieldTy /*place for a value*/,
*mut *const fn()->bool /*next resume address, also tells whether parent coroutine should yield*/
) //`yield`info
)
Then:
-
When a consumer invokes an effectful function, the first thing function does, is set up resume argument address via callback. A place for a next resume argument is set up by via this callback on each (effectful) yield, if the address has changed;
-
When effectful function yields, it sets up yield value, and a pointer to code where to pass control (it returns).
Effectively, this is "runtime place resolution" like thing.
Lifetimes:
for now, because of the rules, labels always have either lifetime of the caller, or local stack frame lifetime.
In case of lifting the rules and allowing full non local control flow...
In this case we treat them as a structs with references (what they in fact are), any label has one lifetime parameter which can be specified like label<'a>(...)
when it's necessary.
Lifetime in signatures are elided, if they are not specified (elision failed => annotation needed).
asynchrony effect syntax:
As of syntax for capturing async env., but not producing a future, I would suggest smth. like fn<async>(...)...
as a notation. I don't think we should allow an async fn
or an async closure to accept this effect.