lang: Remove #[state]

[armaniferrante]

We should consider removing state. The same functionality can be created by initializing PDAs with fixed seeds in the accounts context. E.g., #[account(init, seeds = [b"state".as_ref(), &[bump]])]

Currently, the only benefit of state is that it makes the programming model easier to reason about when coming from Solidity. However, it seems to fight against solana's parallel first programming model, adds more syntax to learn, maintain, audit, and document, and is ultimately less convenient to use because the state struct can't be easily accessed via the #[derive(Accounts)] macro and so constraint validation has to be brought up into the instruction handler, which is less idiomatic.

I'm in favor of removing the syntax and am curious if others agree.

[armaniferrante]

One reason we might want to keep state structs around is for program composition #454. One way to implement composition would be via traits similar to how #[interface] works.

[chenwainuo]

I don't have a strong technical reason why it shouldn't be removed, but as someone very new to the scene, state was the only thing that made sense to me at the beginning.

Although later I realized its limitation, and need to create other PDA accounts, having a central state that keeps tracks of the source of truth always feel nice: (I hope I am doing this right though)

my_program: ProgramState<'info, MyProgram>,
#[account(seeds = [my_program.mint.as_ref(), &[my_program.nonce]])]
pool_signer: AccountInfo<'info>
#[account("myProgram.oracle == *oracle.key")]
oracle: AccountInfo<'info>,

[Standaa]

I am in the "should be removed" camp as I find it antonymic to how Solana works.
I have always considered it to be a workaround made for people coming from the Ethereum world.
The problem is that down the line you get used to passing several accounts in your methods, yet the state account is always accessed differently and has this "magic abstraction" touch to it.

For context, I got in this discussion because I was looking at how to access the state account "outside" the state impl.
Having to pass the state as any other account to my funcs/methods from the start would imo have made it easier to reason about it.

[archseer]

How does one define a interface implementation without #[state]? The documentation handles this by defining an empty #[state] struct then implementing the trait on it: https://docs.rs/anchor-lang/0.18.0/anchor_lang/attr.interface.html#defining-an-implementation

[armaniferrante]

How does one define a interface implementation without #[state]? The documentation handles this by defining an empty #[state] struct then implementing the trait on it: https://docs.rs/anchor-lang/0.18.0/anchor_lang/attr.interface.html#defining-an-implementation

The current #[interface] mechanism requires #[state].