https://go.dev/cl/555075 proposed implementation of GOEXPERIMENT=rangefunc for x/tools/go/ssa.

I agree that this is needed, and I agree it is cleaner to require the Defer{Into} field in all cases rather than make it implicitly "the current defer stack" when omitted.

Let's use the same name for both fields:

package ssa

type Defer struct {
+   Stack Value // stack (from ssa:deferstack() intrinsic) onto which this function is pushed 
    ...
}
type RunDefers struct {
+   Stack Value // stack (from ssa:deferstack() intrinsic) of functions to call in pop order
    ...
}

(Aside: it would be nice if we could avoid the double indirection of vars plumbed through closures when they are never assigned from within the closure; in the case of deferstacks we know a priori that this is the case.)

Another option is for ssa:deferstack() to be a new ssa Instruction, Stack. The new Instruction would take no arguments and produce a value referring to the stack frame of the current function. The type of the value would be a pointer to an opaque stack type. A new Instruction type would not be backwards compatible with type switches that attempt to be complete over Instructions.

If we start to require the Stack field in Defer and RunDefers, my preference would be to have Stack over ssa:deferstack(). It is marginally easier to deal with Instructions than calls to Builtins and we will expect to have a lot more of these in preexisting code. If we leave the Stack field optional, I do not have a strong preference between a new Builtin and a new Instruction.

(cc @dominikh)

There's no need for a new instruction, so let's not add one. As we've seen from the types.Alias work, breaking existing switches is a very expensive business. Adding new fields (even required ones) to existing instructions is easy, as there is only one algorithm that creates instructions (the builder).

Change https://go.dev/cl/555075 mentions this issue: go/ssa: support range-over-func

The proposal is to add

package ssa

type Defer struct {
+   Stack Value // stack (from ssa:deferstack() intrinsic) onto which this function is pushed 
    ...
}
type RunDefers struct {
+   Stack Value // stack (from ssa:deferstack() intrinsic) of functions to call in pop order
    ...
}

There is significant opportunity for confusion between the call stack and the defer stack. I think the name 'Stack' is not specific enough. It should be 'Defers' or 'DeferStack' or 'DeferList' or something like that.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

There is significant opportunity for confusion between the call stack and the defer stack. I think the name 'Stack' is not specific enough. It should be 'Defers' or 'DeferStack' or 'DeferList' or something like that.

Users never populate this field, they only read it, and the doc comments will make clear that it refers to the logical (opaque) stack of deferred functions. (I can't see what stack-of-calls it could be confused with.)

None of these seem like arguments against 'DeferStack' instead of 'Stack'.