Russ Cox

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

@bcmills, my experience over >25 frustrating years of trying to benchmark things is that, in general, attempting to subtract out per-loop overhead sounds good in theory, but in practice that...

The main place where testing.Keep is needed is around the overall result. I write code to work around that all the time. It is far less common to need to...

I see now that you also mentioned making b.Iterate a compiler intrinsic. I suppose that is possible, but it seems very special-case. At that point it's basically a back-door language...

The stack frame implementation would not be able to set up the arguments just once. It would have to set them up on every iteration, since in general a function...

I am still concerned about the overhead of reflect in Iterate. We can't subtract it, and that means we can't reliably measure very short functions - which are the ones...

We are considering Keep and Loop-with-implicit-Keep together. (And the place for that combined discussion is this issue, not #61515.) If we do the special casing, then we basically have to...

To summarize the current state, the idea is to have Keep(x) return x but "hide" it from the compiler and disable throwing it away, so you can use Keep(f(Keep(x))) to...

Why does it matter? The type alias and its actual definition should be equivalent?

I understand now, thanks. The go/types API historically did not expose any information about aliases, so this is the best wire could do. The right answer is probably to make...