Abilities instead of Resources?

Hello! I’ve noticed this huge PR and wonder what are abilities? And how do they differ from resources? And what is the background for this feature?

Do I understand it correctly that store ability is what was a resource and copy is not a resource? Then what are drop and key ones?

1 Like

There will be more documentation forth coming. I had wanted to have that land with the PR, but due to time constraints, the documentation didn’t land with the change. Sorry about that.

The first form of documentation will be a high-level changelog for people already familiar with the language. And then deeper documentation on the Move developer document page.

Roughly speaking:
resource becomes key and store
copyable becomes copy, drop, and store

Each ability grants interaction with various builtin operations

  • copy allows values of the type to be copied, via copy (Copying a local) or *e (De-reference)
  • drop allows values of the type to be dropped on the flow, via e; (Pop), *e = e (Reference mutation), or x = e (Assigning to a local)
  • key allows values of the type to be used as top level “resources” in global storage. That is move_to<t>, move_from<t>, borrow_global<t>, borrow_global_mut<t> and exists<t> all require t: key
  • store allows for the value to exist in a key struct in global storage. In example, move_to<S>(account, S { f1, f2 }) you need S: key and for each f1: t1 and f2: t2 the types of the fields need store t1: store and t2: store

There is some clever things going on with generics but I’m not sure I can explain that concisely right now in this post, so that will have to wait for the changelog/docs

3 Likes

Quick and perfect intro! Will try to experiment myself to find out more about these behaviors. Is it the only major change that happened to the language recently? Or maybe you have something coming?

  • A function can be declared with script visibility (syntax: public(script)). A script function can only be called from other script functions (i.e., not private functions or public functions). In Diem, a script function can be called by name from a transaction (instead of requiring a tx to include an entire script program).
  • Modules have a friends <addr1::Module1>, <addr2::Module2> section, and a function can be declared with friend visibility (syntax: public(friend)). A friend function of module M can only be linked against/called by one of the modules in the friend section of M.
  • We have added a VM API for module updates with backward compatibility checks (e.g., ensuring that resources and functions aren’t deleted).
2 Likes

Thanks! Already seen some of them, didn’t know that friends got merged!