Closed cryptopapi997 closed 4 weeks ago
@cryptopapi997 is attempting to deploy a commit to the coral-xyz Team on Vercel.
A member of the Team first needs to authorize it.
Currently the program ID is exported as
static
. Exporting it asconst
would allow for using it inside ofconst
functions for compile time checks and derivations (e.g. https://github.com/cavemanloverboy/const-crypto) without much downside.
I think the only downside would be the increased binary size, as static
s in Rust have a fixed memory address, but const
s are just copied as is for each use.
I'm not opposed to this change if it's going to be helpful.
This change could potentially make sense inside
declare_id!
as well, but holding off from this for now, as I don't know to what extent this might break backward compatibility. However, if we consider this as a breaking change inside ofdeclare_program!
anyway, I'd opt for extending this to also include this change insidedeclare_id!
.
This could potentially be a breaking change in some rare cases since static
and const
behave differently.
I think the only downside would be the increased binary size, as statics in Rust have a fixed memory address, but consts are just copied as is for each use. I'm not opposed to this change if it's going to be helpful.
I think this mostly negligible, as this only applies for the program ID which is only 32 bytes.
This could potentially be a breaking change in some rare cases since static and const behave differently.
True, and this also applies for declare_program!
and declare_id!
. If we consider it a breaking change for that (i.e. it would only get released in 0.31.0), I'd opt to also include changing this inside declare_id!
to get it over with "once and for all". Wdyt?
Currently the program ID is exported as
static
. Exporting it asconst
would allow for using it inside ofconst
functions for compile time checks and derivations (e.g. https://github.com/cavemanloverboy/const-crypto) without much downside.This change could potentially make sense inside
declare_id!
as well, but holding off from this for now, as I don't know to what extent this might break backward compatibility. However, if we consider this as a breaking change inside ofdeclare_program!
anyway, I'd opt for extending this to also include this change insidedeclare_id!
.