snd

for actually using contracts (not testing) there would be a default Context implementation which would delegate to `extern "C" fn`

to clarify: i'm proposing an attribute or macro which makes a smart contract and it's ABI from a module like definition. functions within that definition take a `C: Context` as...

@fckt i prefer `context.storage_write` over `context.storage().write` as well

@fckt >`pwasm-std` could provide the real context with external calls and we could pass it in `_call`. 👍

@NikVolf great that we start a discussion on this the points you raise focus on the removal of the trait in the example. **do you see any downsides to passing...

the trait stuff is clear to me. just thought 1) and 2) were essentially the same point and wanted to know whether there's more to it.

> Like so https://play.rust-lang.org/?gist=6570adb28cbd3bb1c139e08389a6a12b&version=stable i already like this much better than the current way 👍 i don't like that the following nontrivial boilerplate is now required for every contract: ```rust...

why `ctor` if i may ask? unless one comes from C# it will cause confusion. confusion leads to bugs. why not `constructor`? it's unmistakeable!

> Name ctor comes from how Solidity encodes call to the constructor. https://github.com/paritytech/pwasm-abi/blob/master/derive/src/lib.rs#L95 isn't that an implementation detail that shouldn't affect the public API?

just looked at https://play.rust-lang.org/?gist=6570adb28cbd3bb1c139e08389a6a12b&version=stable again in the test at the bottom: having to use explicit blocks and recreating the contract many times because the contract exclusively mutably borrows the context...