Storage API improvements

[turbolent]

Issue To Be Solved

@MaxStalker pointed out that current storage API has some shortcomings in functionality and usability issues, and proposed several improvements:

• Overwriting stored values: It should be possible to overwrite storage content. Currently save aborts the program if the target path already stores a value, and a load and destroy is needed to clear the storage path before being able to save.

  Maybe add a fun forceSave<T>(_ value: T, to path: Path) function, which would overwrite storage at the specified location, destroying the resource which is potentially stored

• Removing stored values: Currently, stored resources can be removed by using the load function and the destroy statement. Value types can not be removed.

  Maybe add a fun clear(_ path: Path) function, which would clear storage at specified location

• The load, copy, and borrow functions, as well as the capability borrow function, currently return nil both when the storage location is empty, and when the storage location contains a value, but is does not have the requested type. The inability to differentiate the two cases makes debugging hard.

  The function has basically three return value cases:

  1. Nothing is stored
  2. A value is stored, but it does not have the requested type
  3. A value is stored, and it has the requested type

  For case 2:

  • Maybe abort the program, i.e. treat the requested type as a force-cast.
  • Maybe the emulator should log a warning that

• There is no way to check if there is a value stored for a given location.

  Maybe add a fun type(at path: Path): Type? function, which returns the type of the value stored at the given storage location, if any, and nil otherwise

  Also initializing a storage path in case it is empty is error prone:

   if acct.borrow<&KittyItems.Collection>(from: KittyItems.CollectionStoragePath) == nil {
    acct.save(<-KittyItems.createEmptyCollection(), to: KittyItems.CollectionStoragePath)
  }
  

  Here, the borrow might fail (return nil) and the save might still error, if the borrow tried to borrow using a different type.

• Related, functionality to query stored values should be added (see #208)

[10thfloor]

Should we split this into separate issues?

[turbolent]

@10thfloor Definitely, for now it's basically just a place to gather potential improvements, but once it's well defined we can make it an epic, and then should/will create individual issues for each of the items!