Token program instruction builders dont support token2022

[Jac0xb]

Issue

• Token programs have hard coded legacy token program in the instruction builders.

[sonicfromnewyoke]

I think it is ok, and there will be another lib token-2022 with almost a copy-paste code from the legacy token program with hardcoded TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb.

The same approach was used in fndn

[Jac0xb]

I do not hold the original libs in high regards. This seems like a poor use of bytecode space if I am including these in my onchain program. Almost all the instructions are identical and there could easily be a field in the struct for token program rather than needing to depend on two packages and have conditional logic that duplicates the code for each version.

[sonicfromnewyoke]

I do not hold the original libs in high regards

makes sense

[Nagaprasadvr]

In Most cases ppl won't be using both token and token-2022 program .
But it makes sense, this can be done with an enum, will increase 1 byte for ix data and
Few cus per ix ig wyt @febo

[febo]

Since token-2022 is a superset of the token instructions, perhaps the token-2022 client should include the token program as a parameter. This way it can be used for both token and token-2022.

[Nagaprasadvr]

so we just move all token ixs to token-2022 client and add an enum field to mark whether legacy or token-2022 ig

[febo]

so we just move all token ixs to token-2022 client and add an enum field to mark whether legacy or token-2022 ig

Not sure if we need an enum field. We could have a field for the token program's AccountInfo and use the key from there.

[Taylor123]

Has any more thought been put into Token2022 support? Would be great to have the token crate support both.

[Nagaprasadvr]

Has any more thought been put into Token2022 support? Would be great to have the token crate support both.

I have a pr tat i was working on #36