Investigate foreign trait exposing

[HDauven]

Summary

Foreign traits can have interfaces but also default implementations. These default implementations can theoretically allow for the scaffolding of full contracts that adhere to a standard.

The primary problem we have is that the foreign trait with the default implementation needs to have access to the state and needs to expose the call to the VM.

Possible solution design or implementation

Investigate if it is possible to expose the foreign trait implementation and/or interface to the implementing contract.

The foreign trait implementation should have its call function generated if public AND have access to the contract state.

For the trait functions, #[no_mangle] functions can be generated. How it will access the state is a different matter that needs a further look. Maybe introducing the #[contract] macro with an opinionated state structure.

[Neotamandua]

• Traits cannot access state or struct fields in default implementations.
• It is not possible to define a standard with a trait if you want to add elements like events (which could be mapped through structs but not within a trait since traits describe behavior, not data formats).
  • Technically, you could add get_field/set_field methods for struct fields, but this approach is questionable in my opinion. You would always need to implement something yourself.
• Using generics such as associated types or a state generic used in the traits default implementation still cannot give you access to fields that a struct might have that wants to implement the trait.

Java/C# interfaces and Solidity interfaces or abstract contracts differ from Rust's traits. The inheritance of classes/contracts that implement an interface is not really supported in Rust.

Technically, macros could be used to conditionally expose functions (excluding predefined keyword functions like set_state) and maybe even auto generate the needed setters/getters in a struct, but this complicates the design and moves away from idiomatic Rust. Implementing an interface and inheritance behavior within Rust like Solidity supports it (with abstract contracts or interfaces) will lead to some sort of eDSL.

[Neotamandua]

Higher level insights:

• We may have more functionality to define a standard not necessarily as a trait, but as a whole module (pub mod), where there is a trait within it that exposes the public "interface"
• The standard implementation resides in the module through a struct or something else that you can import.
• You can have your own implementation by importing the trait and implementing the public interface and your own internal logic.
  • This could lead to an approach where you compose contracts by having them inside a composite struct that keeps the sub-contracts as fields. However, this raises the question of how to re-expose the underlying functions to unsafe no-mangle with a macro, or even two macros.

---

• Have a #[derive(TokenStandard)] or #[standard(TokenStandard)] macro on top of a struct
  • This macro would automatically generate the functionality on top of the struct, check that the required fields are within the struct & could also automatically generate tests (to ensure the standard works correctly). However, it is not straightforward here to "override" the functionality of the standard functions being generated. This could work if you have the macro on top of a mod where the macro detects if there is an impl function with the same fn signature already.

---

• Dev tooling with template functionality.
  • This would basically just create a project (like a contract wizard or cli) that you could then use directly and set the properties or add your own code logic or modify existing code logic. What these templates look like or what they contain (traits etc) needs to be discussed.

In general, to create contracts based on standards (which may be extensible) we can use a builder pattern to provide the variability and property setting as an alternative to a constructor approach.

[Neotamandua]

For clarity: The previous answers included a wider scope not addressed in the original question

Final summary:

• Traits on standards can not have default implementations. We do not want to support this approach.
• We don't support any form of actual OOP or inheritance, except for what is idiomatic Rust. The goal is to be as much rust idiomatic as possible
  • There will be no inheritance of existing contracts, objects whatsoever
  • For clarity:
  • Existing deployed contracts can be used & called through inter-contract calls. (e.g., contracts intended to be a library). They don't necessarily have a state.
  • You can use existing code (e.g., contracts) as a template or by forking it to modify the code directly. Not inherit them.
  • You can write a no-std library. Those libraries can be a dependency in your build. They are stateless and do not make assumptions about state, therefore can be labelled as "pure". (To do: Investigation if something prevents you to have 2 states, one used by the library & one used by the contract)
• We are not building an eDSL yet. That is something possible for the future
• We aim to have a macro on top of modules (pub mod)
• If there are multiple macros, they need to be linked
• We want to hide the static mut STATE & auto generate the no_mangle

We should now start with atomic issues, the first one being: Macro to hide static mut state & no_mangle