Why trait defintions don't support generic

[yjhmelody]

I find trait cannot be generic

        if !item_trait.generics.params.is_empty() {
            return Err(format_err_spanned!(
                item_trait.generics.params,
                "ink! trait definitions must not be generic"
            ))
        }

But I want to define environment-independent traits, such as:

#[ink::trait_definition]
pub trait Ownable<E: Environment> {
    /// Initializes the contract setting the deployer as the initial owner.
    #[ink(constructor)]
    fn new() -> Self;

    /// Returns the account id of the current owner.
    #[ink(message)]
    fn owner(&self) -> Option<E::AccountId>;

    /// Transfer ownership to new owner.
    #[ink(message)]
    fn transfer_ownership(&mut self, new_owner: Option<E::AccountId>);
}

[Robbepop]

We are currently working to make ink! trait definitions really usable and afterwards this feature is going to be very important in my opinion. The ability to define ink! traits environment agnostic is not MVP but really needed.

[atenjin]

Hi @Robbepop

Yes @yjhmelody is our guy who is working for Ask! Same to ink!, we need to design interface or something else for supporting designing specification. And for now, we think ink! trait_definitions can not cover many scenes, just like this issue #683 (in fact the scenes listed in this issue are also incomplete)

and in your pr #665, It seems that it can't solve many cases either. Thus, is there existed a formal issue or discussions or channal to discuss the design for trait_definitions?

[HCastano]

@Robbepop We might want to have a separate issue for discussions and designing generics - I can't find anything in the issue tracker

[Robbepop]

Let us first get non-generic traits right and then we can tackle making them generic or adding similar features that will help with library-like smart contracts that are urgently needed.

[Robbepop]

This is going to be fixed in #665 where all ink! trait definitions are generic over an ink! contract environment.

[SkymanOne]

The issue has been fixed by #665