Green Baneling
Green Baneling
> Why u128 for the key? Since it is only a counter now we can get away with u32. This would map to a primitive operation in wasm. If you...
> We think the best way forward would be to iterate on your example and get rid of the unsafe transmute. For the host functions you could mock them for...
> 1.1 vs 1.2: Given that these are the only two options I am leaning to the explicit solution. That said, I didn't put nearly as much thought into it...
"atomic struct" - all fields are atomic. All types are atomic except `Storage` and `Mapping`. > I think we should go with the first solution (numeric key and explicit generics)....
> I don't get it. How would we do that if we are generating the key from a name? Hash the name at compile time and truncate to 8 byte?...
> Given these numbers I might be inclined to say that truncated hash version might be better if it is substantially simpler and gets rid of generics for the user....
We can add `XOR` part to `AutoKey`: ```rust /// The final storage key = Key ^ XOR. struct ManualKey; /// The auto-generated storage key(based on the name of the stuct...
> The macro should be able to detect that there is a const Key specified and use it. We can try to automate that process. For that, we need some...
> @xgreenx Regarding `#[ink(storage)]` and `#[ink::storage_ext]`: In an ideal world we would need only `#[ink(storage)]` and detect if the `struct` is meant to be the top-level storage item or a...
We included that issue in our roadmap, so we are waiting for approval from ink! team to start work on it=)