Align StorageMap interface more with Rust's {Hash,BTree}Map

[apopiak]

The interface of StorageMap mostly keeps to the interface of Rust's HashMap and BTreeMap except that it renames contains_key to exists.

I think it would make sense to either rename the function to the Rust name (contains_key) or create an alias.

[bkchr]

Will you want to do this @apopiak? As discussed in Riot, this should be done in a timely manner.
I don't think that anyone has any problems with this change.

[apopiak]

Yep, will take on.

[apopiak]

I'm sorry to do this now instead of earlier, but I noticed another discrepancy:
StorageMap::take is called
HashMap::remove in the original, while StorageMap::remove doesn't really have an equivalent (you just remove and drop the value).
HashMap::take does not exist, but HashMap::drain()::take() does which could lead to confusion.

[apopiak]

Also it's not a huge deal, but you remove a StorageValue with kill and a StorageMap entry with remove.

[bkchr]

I'm sorry to do this now instead of earlier, but I noticed another discrepancy:
StorageMap::take is called
HashMap::remove in the original, while StorageMap::remove doesn't really have an equivalent (you just remove and drop the value).
HashMap::take does not exist, but HashMap::drain()::take() does which could lead to confusion.

I think this is fine, that is just something where we diverge from a default hashmap.

Also it's not a huge deal, but you remove a StorageValue with kill and a StorageMap entry with remove.

I would expect that StorageMap::kill would remove the whole data structure (currently this function is called remove_all).

[apopiak]

I think this is fine, that is just something where we diverge from a default hashmap.

ok

I would expect that StorageMap::kill would remove the whole data structure (currently this function is called remove_all).

right, makes sense