Has anything changed since #7007 was declined?

#7007 seemed to be asking for the ability to get the tags in an arbitrary package in order to do conditional logic. It was thus rejected because doing that was deemed hacky, and there didn't appear to be a legitimate reason to need them at runtime. But I've found that at least being able to log what they were would be very useful, similar to how we can log runtime.Version() today. I don't intend to be performing if checks with them or any such thing.

Something that has changed in the recent years is the addition of https://golang.org/pkg/runtime/debug/#ReadBuildInfo. One could say that the list of build tags is part of the running binary's build information.

@mvdan I don't think that runtime/debug is the best place to record the build tags, since that would cause the build cache to be invalidated for all packages that directly or indirectly import that package whenever the set of build tags changes. It is for this reason that I think embedding them directly in main is a better choice, since if I'm changing build tags, I pretty much expect at least main to change. (And the implications of a cache invalidation for the main package are lesser, since nothing should be importing it anyway.)

Unless writing them into runtime/debug can be deferred until link time? Not sure what's feasible.

@rittneje, the contents reported by runtime/debug.ReadBuildInfo are already injected more-or-less at link time by the go command. They shouldn't have any effect on cacheability for runtime/debug itself or the packages that (directly or indirectly) depend on it.

I think that was done recently for 1.18:

$ go version -m XXX
[...]
build	tags	testcover,race,goexperiment.regabiwrappers,goexperiment.regabireflect,goexperiment.regabiargs,goexperiment.pacerredesign
[...]

It is also available via Settings field.

I guess it can be closed?

This proposal has been declined as retracted.
— rsc for the proposal review group