Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Default trait on user-defined IDL structs #6

Open
losman0s opened this issue Jul 25, 2022 · 4 comments
Open

Custom Default trait on user-defined IDL structs #6

losman0s opened this issue Jul 25, 2022 · 4 comments

Comments

@losman0s
Copy link

Is there a way to handle custom Default trait definition for some of the Defined structs, e.g.:

{
  "name": "MyStruct",
  "type": {
    "kind": "struct",
    "fields": [
      {
        "name": "authority",
        "type": "publicKey"
      },
      {
        "name": "reservedSpace",
        "type": {
          "array": ["u128", 256]
        }
      }
    ]
  }
}

atm the explicit sizes (0-32) in the standard implementation prevents generation:
the trait 'Default' is not implemented for '[u128; 256]'

@losman0s
Copy link
Author

Not sure if notifications go through so will try pinging @macalinao

@macalinao
Copy link
Member

This specific case is fixed. We should probably add a way to explicitly specify that a Default should not be generated for a type though

@losman0s
Copy link
Author

This specific case is fixed. We should probably add a way to explicitly specify that a Default should not be generated for a type though

Great thanks! One last clarification though: I don't get the use case for the separation between anchor_gen::generate_cpi_crate and anchor_gen::generate_cpi_interface. The former, shown in the README, seems to only be a "forced defaults" of the latter.

  1. Am I missing something
  2. If not, it might be valuable to avoid confusion by either explaining the distinction, or using anchor_gen::generate_cpi_interface in teh README (although I agree examples are pretty helpful in any case)

@macalinao
Copy link
Member

Backwards compatibility. Maybe we should mark the other one as deprecated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants