Russ Cox

It sounds like we are having trouble getting to an API that will actually guarantee zero allocations and that is simple enough to be a reasonable API change. Does anyone...

It still sounds like we don't have a final API to decide about, one that will guarantee zero allocations and is simple enough to present to users. Does anyone want...

Is Caller just a cache for allocated things? If so, maybe it shouldn't embed the receiver? That is, maybe it should be var caller reflect.Caller caller.Call(v, args) because then you...

Sounds like we are waiting on someone to implement this to understand whether it satisfies the performance goals for the proposal.

**[Placed on hold](https://golang.org/s/proposal-status#hold)**. — rsc for the proposal review group

The implemented API seems to be: ``` package reflect type Caller struct { ... } func NewCaller(v Value) *Caller func (c *Caller) Call(rcvr Value, in []Value) []Value ``` This lets...

@nrwiersma thanks for the reminder about CallSlice. It seems like Caller should have both Call and CallSlice methods. Then both Value.Call and Value.CallSlice would be wrappers. @twmb, @dsnet any thoughts?

So the current API is: ``` type Caller struct { ... } func (v Value) Caller() *Caller func (c *Caller) Call(rcvr Value, in []Value) []Value func (c *Caller) CallSlice(rcvr Value,...

It sounds like people are generally in favor of func BinarySearchFunc[E, T any](x []E, target T, cmp func(E, T) int) (int, bool) Is E, T the standard order in other...

Based on the discussion above, this proposal seems like a **[likely accept](https://go.dev/s/proposal-status#likely-accept)**. — rsc for the proposal review group