Open invariants in async/await and async blocks. #1873
FeizaiYiHao
started this conversation in
Language design
Replies: 1 comment
-
|
Invariants: Yeah, this sounds right to me. Conceptually, I'd consider a yield to be an operation that is "opens_invariants any", which effectively rules it out from being used in open_invariant blocks, or in functions with anything less than the default "opens_invariants any" in its signature. Async blocks: This will probably require a bit more investigation. As I understand it, these are like closures, but they're a different "kind" of closure, and I don't know much about them right now. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I'm planning to add support for open invariants in async functions and add support for async blocks. Please let me know if these makes sense.
Open invariants
Conceptually, as long as any
open_invariantsblock doesn't contain yield points, we'd be fine.The only yield point in Rust is
await. Luckily, Rust does not allow yield points in non-async functions. Even if a regular function has anasyncblock, which may containawait, the block returns a future that is lazy and will not do anything unless it is calledawaitin someasyncfunctions.Therefore, as long as
open_invariantsdoes not call async functions orawait, the execution wouldn't yield.So all we need to do is to traverse the expressions and statements in each
open_invariantsblock and make sure there are no calls toasyncfunctions orawait.Async blocks
On a high level, I think it should work similarly to async functions (so with postconditions), since async functions are desugared into a function with a large async block. I'm not sure how to handle this elegantly. Should it be handled similarly to
closure?Beta Was this translation helpful? Give feedback.
All reactions