-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
proposal: Allow const values to be changed through build flags before compilation #22706
Comments
It's not a bad idea but I don't see any way to implement it. The problem is that the compiler knows that constants can't change, and it optimizes code on that basis. You are proposing a way that a constant can change after the compiler has already run. I don't see a way to do that. |
The way I understood the proposal, this wouldn't change the constant after the compiler has run. It would be a new flag to the compiler (not the linker's -X flag) that overwrites a constant's value before compilation. |
Ah, got it, sorry, similar to C's |
I've tweaked the title a little, please feel free to revert or edit it. |
If you have a small set of possible values you could choose from among them with build tags (one file per value with appropriate build tags). |
The |
If it's just about one or a few constants, you could just as well
This is a third method of achieving the same goal. I don't see any reason for adding an additional mechanism to the compiler. |
@griesemer And the way to capture that echo is with |
@robpike With all due respect, but Also the proposed option with Like mentioned above GCC argument And finally people do actually use |
@akamensky I'll have others (@ianlancetaylor?) chime in on the various reasons for linker flags but regarding the constant issue, using In order words, if you are willing to provide a compiler flag you might just as well execute the little |
@griesemer yes, I do not disagree. It is possible to do that, my previous comment was about above insisting on using |
@akamensky I think it is an elegant solution. One of the most important things in system design is knowing where to solve a problem. You can't solve every build problem with compile-time flags. Any realistic build system for a large program deals with enough complexity already that invoking "echo" somewhere is a minor inconvenience at best. Or to put it another way, making a continuous build bot easier to set up is not a convincing argument, at least to me, for putting code generation into the compiler's command-line arguments. |
The ldflags -X option is undeniably useful but also has been a source of confusion. I can only imagine the confusion that would result from changing constants. What happens when you do
? If you want to control debug settings, then build tags work too, as @randall77 noted already. That's certainly better. We should almost certainly draw the line just after -X for vars. |
I often find myself in need to define some value that should never ever change during the application runtime (e.g. release version). Idiomatically this supposed to be a
const
, however if I need to set value to it compile-time in Go1.x I am restricted to usingvar
only, which often makes no sense (as in example with release version)Currently
var
value can be assigned at linking stage by passing-ldflags "-X main.varname=varval"
.I propose to allow setting constants during compile time in same or similar manner.
From my perspective it looks as this won't be a backward compatibility breaking change, so it would be possible to implement in Go1.x (otherwise, perhaps, this can be moved to Go2)
The text was updated successfully, but these errors were encountered: