fitzgen opened issue #8940:
Performing a GC requires
&mut
though, right? So given&StoreOpaque
that's static proof that a GC won't happen?Musing though: because
unchecked_try_gc_ref
returns a lifetime bound to&StoreOpaque
doesn't that mean that GC is already statically disallowed while we're working with thegc_ref
? If that's the case could theunchecked_
prefix be removed? (fine to defer this to a future PR of course)_Originally posted by @alexcrichton in https://github.com/bytecodealliance/wasmtime/pull/8933#discussion_r1674184310_
Note: we can't just remove the
unchecked_
prefix, since there are versions of this method already named those things, but they take aAutoAssertNoGc
instead of a `&StoreOpaque. So it isn't clear what naming conventions we want to have here. Or we could make a trait that represents stores/contexts where we can rest assured that GC won't happen while that store/context type exists.Feel free to bikeshed.
alexcrichton closed issue #8940:
Performing a GC requires
&mut
though, right? So given&StoreOpaque
that's static proof that a GC won't happen?Musing though: because
unchecked_try_gc_ref
returns a lifetime bound to&StoreOpaque
doesn't that mean that GC is already statically disallowed while we're working with thegc_ref
? If that's the case could theunchecked_
prefix be removed? (fine to defer this to a future PR of course)_Originally posted by @alexcrichton in https://github.com/bytecodealliance/wasmtime/pull/8933#discussion_r1674184310_
Note: we can't just remove the
unchecked_
prefix, since there are versions of this method already named those things, but they take aAutoAssertNoGc
instead of a `&StoreOpaque. So it isn't clear what naming conventions we want to have here. Or we could make a trait that represents stores/contexts where we can rest assured that GC won't happen while that store/context type exists.Feel free to bikeshed.
Last updated: Nov 22 2024 at 17:03 UTC