Feature
Refs #7688 #7676
Currently, developers can define resources via Linker::resource, but they can not get a handle to the Resource<T> from a ResourceAny, which is passed to e.g. Linker::func_new functions.
Benefit
Most importantly, it allows usage of resources for dynamically-typed functions, e.g. such as when WIT definition is not known at compilation time
Implementation
This should be quite similar to #7688, we should make sure to account for the own/borrow state and possibly call the destructor on Drop
Alternatives
The only alternative seems to be not supporting dynamically-typed functions utilizing resources, developers may use macros/templating to generate all possible type bounds of imported functions at compile time and choose the right one at runtime, but that is very complex and hard to maintain
A reasonable alternative could be using the "partially-typed" bound with #7701, but it still seems preferable to support fully-dynamic use cases
Feature
Refs #7688 #7676
Currently, developers can define resources via
Linker::resource, but they can not get a handle to theResource<T>from aResourceAny, which is passed to e.g.Linker::func_newfunctions.Benefit
Most importantly, it allows usage of resources for dynamically-typed functions, e.g. such as when WIT definition is not known at compilation time
Implementation
This should be quite similar to #7688, we should make sure to account for the own/borrow state and possibly call the destructor on
DropAlternatives
The only alternative seems to be not supporting dynamically-typed functions utilizing resources, developers may use macros/templating to generate all possible type bounds of imported functions at compile time and choose the right one at runtime, but that is very complex and hard to maintain
A reasonable alternative could be using the "partially-typed" bound with #7701, but it still seems preferable to support fully-dynamic use cases