Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Vec in storage, potentially starting with a new type StorageVec #2035

Closed
mohammadfawaz opened this issue Jun 17, 2022 · 1 comment · Fixed by #2048
Closed

Implement Vec in storage, potentially starting with a new type StorageVec #2035

mohammadfawaz opened this issue Jun 17, 2022 · 1 comment · Fixed by #2048
Assignees
Labels
enhancement New feature or request lib: std Standard library

Comments

@mohammadfawaz
Copy link
Contributor

mohammadfawaz commented Jun 17, 2022

Vec<T> cannot be used in storage today because its data is heap data. Ideally, we would be able to have a type Vec<T> that behaves differently depending on whether it's declared inside a storage block or outside it.

  • If declared outside a storage block, then Vec<T> and its methods would behave exactly as they do today.
  • If declared inside a storage block, then Vec<T> and its methods would store and access its data from storage instead of the heap.

A good starting point however is to implement StorageVec<T> with the same API as Vec<T>, but uses persistent storage instead of the heap.

@mohammadfawaz mohammadfawaz added enhancement New feature or request lib: std Standard library labels Jun 17, 2022
@SwayStar123 SwayStar123 self-assigned this Jun 18, 2022
@SwayStar123
Copy link
Member

I would like to start implementing a seperate StorageVec type right now

@adlerjohn adlerjohn linked a pull request Jun 19, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request lib: std Standard library
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants