cc: @findleyr

I think this is the simplest change implementing support for zero, and would allow us to migrate to the new Value Object type, which is probably what we would have chosen had the go/types API been designed with both nil and zero in the language.

However, I've thought about this a bit more since our brainstorming session, and am concerned that by not introducing a new node type, code could become subtly broken rather than panicking. For example, I grepped x/tools for types.Nil, and found this:
https://cs.opensource.google/go/x/tools/+/master:gopls/internal/lsp/semantic.go;l=497;drc=b35949e23814650f4c5caf482adbf63b6550fead

When encountering zero, that code would highlight the first three characters of zero in a different color, rather than panicking. I don't think that code is technically incorrect. The current documentation for types.Nil is Nil represents the predeclared value nil. Unfortunately that's a rather explicit API, and probably not one we can change in this way.

So, alas, we probably need a new object type Zero, along with the UntypedZero type.

I'm sure I don't have sufficient context here, but what is it about the identifier "Value" that suggests zero- or nil-ness ?

Not sure I interpret the question correctly, but if we introduce a new types.Object Value, it simply stands for some value (like Const stands for a constant, Func stands for a function, etc.). Since it's not a constant, we don't know the explicit value, but we know the type. So nil would be represented as a Value with Value.typ = types.Typ[UntypedNil], and zero would be represented as a Value with Value.typ = types.Typ[Untyped.Zero].

Currently, the CL makes Nil and alias of the new Value. Alternatively, we can keep Nil as is.

(I'd still prefer introducing Value as a general value object than having a Zero object.)

Per discussion, perhaps it's OK to use Value after all.

Rationale: types.Nil still means nil for code written for Go 1.21 and below. Tools seeking to support Go 1.22+ must be updated anyway. I think it's a compatibility gray area, and if it would be more ergonomic to make this change I think it's OK.

We could simply use the Nil object for both

I think that would be better: just add a doc comment to Nil saying that if its Type() is Typ[UntypedZero] then it represents zero. The new name Value is confusing because it sounds similar to TypeAndValue, and constant.Value, but is in fact unrelated.

I understand the concerns about the name Value, but it doesn't make a ton of sense to look up "zero" and get a Nil. I still think we should choose a new name, and make Nil an alias. The spec calls nil a "predeclared value", which is why Value is natural, but you're right that it is somewhat vague and overloaded.

Unfortunately, I can't think of anything better than Value. (PredeclaredValue and UntypedValue come to mind, but are too long and specific).

Closing this as #61372 was declined and closed. We can always revive if needed.

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

If this is active, shouldn't it be reopened?

@rsc's comment was probably from a script. We will remove this proposal from the active column in the next review. The reason for this proposal, issue #61372, was closed so this issue is moot.

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