-
Notifications
You must be signed in to change notification settings - Fork 28
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
Remove the BoundedStorable requirement #69
Comments
Hey @lastmjs! We were just having discussions about the roadmap for stable structures, and this is definitely one of the higher priority changes we'll be working on. |
Any update on this? |
Thanks for the update, very excited |
## Problem We'd like to expand the functionality of `BTreeMap` to support unbounded types. To add this support in a backward-compatible way, the `BTreeMap` would need to support both bounded types (i.e. types that implement `BoundedStorable`) and unbounded types (i.e. types that don't implement `BoundedStorable`). Rust doesn't support generic specializations, so we cannot have the same `BTreeMap` support both use-cases simultaneously. It can either support only `BoundedStorable` types, or all types implementing `Storable`, but without the knowledge of whether a `BoundedStorable` implementation is available for those types. ## Solution Merge `BoundedStorable` and `Storable` into the same trait. The one downside of this approach is that checking whether or not a bound exists now happens at run-time. This impacts the developer experience. Prior to the PR, if you try to store a `String` inside a `StableVec`, the compiler will complain that `String` doesn’t implement `BoundedStorable`. But, with this solution, it’ll happily compile, and only when you run your code will you see a panic that `String` is not bounded. This PR relates to #84 and #69.
Just updating this thread, I'm testing this locally in Azle and so far all is well. Once this is officially released I'd say we can close this issue. |
Version 0.6.0 has been released today, so we can say that this ticket is now resolved. |
Amazing!!! |
Currently all values that are to be stored in a stable structure (as far as I know) require the
BoundedStorable
trait to be implemented. This requires the developer to reason about possible maximum and fixed sizes of all of their data types, recursively, and is a significant hurdle to the developer experience of stable structures.At Demergent Labs we have exposed TypeScript and Python versions of the stable structures library to developers, and we plan to use stable memory, and hope to use stable structures, under-the-hood to implement our sudodb/sudograph databases. If we have to implement the
BoundedStorable
trait for the databases, we will be exposing significant complexity to our end users.Not to mention the efficiency concerns. It would be great to have this requirement lifted in the future, which would be a boon to Azle, Kybra, and Sudograph.
The text was updated successfully, but these errors were encountered: