Green Baneling

The `MessageResult` is the only way to pass an error from the ink! level to the caller(from auto-generated code). In some cases, the caller wants to know the reason why...

> But I'm still not convinced that a contract output can be the same in the revert case and in the non-revert case. I'm not saying that the output is...

> Right now, `Result`, a generic type, is a common appearance in our metadata, and if any message returns a `Result`, it'll even get nested. So if we'd have the...

I didn't get how the "reference" should work. For me, it is similar to the `Lazy` type that we have=) Could you elaborate more, please? > This would specifically allow...

> You are right, it's very similar. I think what we had in mind was to give the contract authors some way of trying to encode (or decode) the type,...

It is a syntax for a rare case when the developers need to work with a result of the cross-contract call. Primarily, you work with methods directly like `self.incrementer.get()`. The...

> The first thing I would do here is to see what is possible to achieve with the existing CallBuilder codegen that we are currently using for cross contract calls....

I agree that we don't need to require a `mut` ownership level because, under the hood, we call a host function that behaves similarly for "read" and "write" methods. But...

> The `derive` macro usually iterates over each field of the structure and recursively calls the corresponding method, assuming that fields implement all required traits. But in the case of...

On the way to solving the https://github.com/paritytech/ink/issues/259, we need to solve this problem=) I created a separate task to track it https://github.com/paritytech/ink/issues/1722