diff --git a/docs/datastructures/dynamic-allocation.md b/docs/datastructures/dynamic-allocation.md deleted file mode 100644 index 83ae3cdd0b..0000000000 --- a/docs/datastructures/dynamic-allocation.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Dynamic Storage Allocator -slug: /datastructures/dynamic-allocation ---- - -In the previous section we have seen how the default mode of operation is to spread information -and how we can opt-in to pack information into single cells via `ink_storage::Packed`. - -However, what if we wanted to store a vector of a vector of `i32` for example? -Naturally a user would try to construct this as follows: - -```rust -use ink_storage::Vec as StorageVec; - -#[ink(storage)] -pub struct Matrix { - values: StorageVec>, -} -``` - -However, this will fail compilation with an error indicating that `StorageVec` requires for its `T` to be packed (`T: PackedLayout`) which `StorageVec` itself does not since it always stores all of its elements into different cells. The same applies to many other storage data structures provided by `ink_storage` and is a trade-off the ink! team decided for the case of efficiency of the overall system. -Instead what a user can do in order to get their vector-of-vector to be working is to make use of ink!'s dynamic storage allocator capabilities. - -For this the contract author has to first enable the feature via: - -```rust -use ink_lang as ink; - -#[ink::contract(dynamic_storage_allocator = true)] -mod matrix { - // contract code ... -} -``` - -And then we can define our `Matrix` `#[ink(storage)]` as follows: - -```rust -use ink_storage::{ - Vec as StorageVec, - Box as StorageBox, -}; - -#[ink(storage)] -pub struct Matrix { - values: StorageVec>>, -} -``` - -With `ink_storage::Box` we can use a `T: SpreadLayout` as if it was `T: PackedLayout` since the `ink_storage::Box` itself suffices the requirements and can be put into a single contract storage cell. The whole concept works quite similar to how Rust's `Box` works: by an indirection - contract authors are therefore advised to make use of dynamic storage allocator capabilities only if other ways of dealing with ones problems are not applicable. - - diff --git a/docs/datastructures/mapping.md b/docs/datastructures/mapping.md index c6f10da9f6..6fdf33f3cf 100644 --- a/docs/datastructures/mapping.md +++ b/docs/datastructures/mapping.md @@ -23,7 +23,7 @@ case, each "user" gets their own number. In order to correctly initialize a `Mapping` we need two things: 1. An implementation of the [`SpreadAllocate`](https://paritytech.github.io/ink/ink_storage/traits/trait.SpreadAllocate.html) trait on our storage struct -2. The [`ink_lang::utils::initalize_contract`](https://paritytech.github.io/ink/ink_lang/codegen/fn.initialize_contract.html) initializer +2. The [`ink_lang::utils::initalize_contract`](https://paritytech.github.io/ink/ink_lang/utils/fn.initialize_contract.html) initializer Not initializing storage before you use it is a common error that can break your smart contract. If you do not initialize your `Mapping`'s correctly you may end up with diff --git a/docs/datastructures/opting-out.md b/docs/datastructures/opting-out.md deleted file mode 100644 index 23eaf9d105..0000000000 --- a/docs/datastructures/opting-out.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Opt out of Storage -slug: /datastructures/opting-out ---- - -If you are in need of storing some temporary information across method and message -boundaries ink! will have your back with the `ink_storage::Memory` abstraction. It allows -you to simply opt-out of using the storage for the wrapped entity at all and thus is very -similar to Solidity's very own `memory` annotation. - -An example below: - -```rust -#[ink(storage)] -pub struct OptedOut { - a: i32, - b: ink_storage::Memory, -} -``` - -The the above example `a` is a normal storage entry, however, `b` on the other -hand side will never load from or store to contract storage and will always be reset to -the default value of its `i32` type for every contract call. It can be accessed from all -ink! messages or methods via `self.b`, but will never manipulate the contract storage and -thus acts wonderfully as some shared local information. diff --git a/docs/macros-attributes/contract.md b/docs/macros-attributes/contract.md index e5394a2309..a976b19732 100644 --- a/docs/macros-attributes/contract.md +++ b/docs/macros-attributes/contract.md @@ -33,51 +33,6 @@ off-chain environment provided by the `ink_env` crate. The `#[ink::contract]` macro can be provided with some additional comma-separated header arguments: -### `dynamic_storage_allocator: bool` - -Tells the ink! code generator to allow usage of ink!'s built-in dynamic -storage allocator. - - `true`: Use the dynamic storage allocator provided by ink!. - - `false`: Do NOT use the dynamic storage allocator provided by ink!. - -This feature is generally only needed for smart contracts that try to model -their data in a way that contains storage entites within other storage -entities. - -Contract writers should try to write smart contracts that do not depend on the -dynamic storage allocator since enabling it comes at a cost of increased Wasm -file size. Although it will enable interesting use cases. Use it with care! - -An example for this is the following type that could potentially be used -within a contract's storage struct definition: -```rust -// A storage vector of storage vectors. -use ink_storage as storage; -type VectorOfVectors = storage::Vec>; -``` - -**Usage Example:** -```rust -use ink_lang as ink; - -#[ink::contract(dynamic_storage_allocator = true)] -mod my_contract { - #[ink(storage)] - pub struct MyStorage; - - impl MyStorage { - #[ink(constructor)] - pub fn construct() -> Self { MyStorage {} } - - #[ink(message)] - pub fn message(&self) {} - } - // ... -} -``` - -**Default value:** `false` - ### `compile_as_dependency: bool` Tells the ink! code generator to **always** or **never** diff --git a/sidebars.js b/sidebars.js index ffa9e47b7e..9019db8a04 100644 --- a/sidebars.js +++ b/sidebars.js @@ -46,8 +46,6 @@ module.exports = { 'datastructures/overview', 'datastructures/mapping', 'datastructures/spread-storage-layout', - 'datastructures/opting-out', - 'datastructures/dynamic-allocation', 'datastructures/custom', ], 'Examples': [