ZetaNumbers opened issue #3633:
Feature
Null value for stored types. Underlying data of handle types like
Memory
orInstance
are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?
ZetaNumbers edited issue #3633:
Feature
Null value for stored types. Underlying data of handle types like
Memory
orInstance
are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null. Adds a null store concept.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?
ZetaNumbers edited issue #3633:
Feature
Null value for stored types. Underlying data of handle types like
Memory
orInstance
are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null. Adds a concept of a null store which cannot be accessed or instantiated.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?
ZetaNumbers edited issue #3633:
Feature
Null value for stored types. Underlying data of handle types (
Global
,Table
,Func
,Instance
,Memory
) are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Adds a default constructor for these types in
wasmtime-cpp
bindings.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null. Adds a concept of a null store which cannot be accessed or instantiated.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?
ZetaNumbers edited issue #3633:
Feature
Null value for stored types. Underlying data of handle types (
Global
,Table
,Func
,Instance
,Memory
) are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Adds ability to create these types inside of the const context (static definitions, const functions).
Adds default constructors for these types in
wasmtime-cpp
bindings.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null. Adds a concept of a null store which cannot be accessed or instantiated.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?
ZetaNumbers commented on issue #3633:
Implementation for the first method is partially complete on my fork.
ZetaNumbers edited issue #3633:
Feature
Null value for stored types. Underlying data of handle types (
Global
,Table
,Func
,Instance
,Memory
) are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Adds ability to create these types inside of the const context (static definitions, const functions).
Adds default constructors for these types in
wasmtime-cpp
bindings.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null. Adds a concept of a null store which cannot be accessed or instantiated.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?Anyway this is a marginal problem, so i could just use
Option<Memory>
.
ZetaNumbers commented on issue #3633:
After some thought, i think it's better to stick with
Option<Memory>
. Perhaps we could add a trait to implementMemory
's interface onOption<Memory>
too, but it feels like there's a lot more to explore with this design (like branded types). Perhaps the right path for now would be to add guard types, instead of havingstore: impl AsContext[Mut]
argument on every function.
ZetaNumbers closed issue #3633:
Feature
Null value for stored types. Underlying data of handle types (
Global
,Table
,Func
,Instance
,Memory
) are owned byStore
, so to operate on these handles you passimpl AsContext[Mut]
as an argument. I think it would be useful to add a support for null handle types, which do not have any instance ofStore
they're handle to.Benefit
I am trying to access memory inside of the import function. I am using import memory, so
Caller::get_export
is not an option. I could storeMemory
handle inside of theStore::data
, but to instantiate memory handle you need theStore
. I could useOption<Memory>
, but for exampleMemory::read
already panics if this memory doesn’t belong to store. So I thought perhaps more idiomatic way to solve this would be to create a dummyMemory
for a dummyStore
, create an actualStore
with this dummyMemory
inside, create an actualMemory
using the actualStore
, and replace the dummyMemory
with an actual one. This process could be simplified if there was something likeMemory::null
.Adds ability to create these types inside of the const context (static definitions, const functions).
Adds default constructors for these types in
wasmtime-cpp
bindings.Implementation
wasmtime::store::data::Stored<T>
is used to create handles to aStore
.
- We could add
Stored<T>
null value. Ifstore_id == 0
then it's null. Adds a concept of a null store which cannot be accessed or instantiated.- We could replace use of
Stored<T>
forOption<Stored<T>>
and also focusimpl<T> Index<Option<Stored<T>>> for StoreData
. Perhaps also remove old interface likeimpl<T> Index<Stored<T>> for StoreData
? BecauseStored::<T>::store_id: NonZeroU64
, size ofOption<Stored<T>>
is same asStored<T>
.Alternatives
Perhaps something like
<Store<T>>::map_data
orRawStore
without type params could also help my problem, if that's possible?Anyway this is a marginal problem, so i could just use
Option<Memory>
.
Last updated: Dec 23 2024 at 13:07 UTC