This will make paritytech/substrate#1791 possible

To me, a feature like this is a huge gain in terms of simplicity to hack and build on top of other existing modules, and could add to the virality of the Substrate platform. Ultimately, the pattern that is challenging for runtimes is chaining multiple different pieces of logic together in a single module function.

Let's say for example buying a kitty in a custom runtime module. There may be two distinct steps which are involved here:

1. Checking that balance transfer will succeed and executing that
2. Checking that the token transfer will succeed and executing that

With the current module system, you must write the function like so:

1. Check that the balance transfer will succeed
2. Check that the token transfer will succeed
3. Transfer balance
4. Transfer token

Users cannot in this case consolidate the check/write pattern into a single functional component which then gets serially called by the runtime function.

This would often come up when you want to make a function which combines your own logic with multiple downstream runtime module calls. For example imagine a runtime function which calls 3 other modules to:

• Complete a custom auction
• Transfer some Balance
• Transfer some Asset

All of the functions in this example would be dispatchable functions defined in different modules. As a developer, I would have no easy way to execute all 3 by calling the implementations in their respective runtime module. I would need to copy their implementations, separate it into check and write components, and reorder the logic. At this point, the user has just written a new module which re-implements all of this code in other places...

I had thought about recommending to users to write their module functions in two halves, a check function and a write function. So something like check_can_transfer and make_transfer. However, this fails to work when the actions of one call could affect the ability to successfully check another. For module function which does two transfers might naively be written like this:

• check_can_transfer(10 units to Alice)
• check_can_transfer(10 units to Bob)
• make_transfer(10 units to Alice)
• make_transfer(10 units to Bob)

But if the caller only has 10 units to begin with, then both checks will pass (since state is not updated between checks) but fail later after the transfer to Alice already happened, and cannot be reverted.

The ability to do patterns like this made Ethereum smart contracts and ethereum standards work so well. If we look at the way that contracts like ERC-721 were written by teams like OpenZepplin, you will see there is a base contract ERC721.sol and then multiple "extension" contracts like ERC721Enumerable.sol. These extension contracts work because users are able to add additional check/write patterns on top of an existing base, without having to get too dirty into someone else's code.

when will this feature be available?

One part of it, namely transactional storage, is being worked on in paritytech/substrate#3263.

↑ that was subsumed by paritytech/substrate#6269 and was merged.

I think this can be closed as we now have default transactional behaviour for extrinsics.

Closed with: paritytech/substrate#10806

Would be interested to see if there is any panic catching thing we can do in the runtime too.

The issue is meant to be tracking general try catch where storage transactions are a part of. Let's keep it reopened until we get there.

Yeah storage transactions won't help with panics. Without panic safety we cannot ensure that we always collect fees.

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/future-of-webassembly-and-ink-smart-contracts/428/5

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/the-xpost-bot-is-awesome-but-can-be-make-it-prettier/448/1

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/eliminating-pre-dispatch-weight/400/14