proposal: spec: permit using nil with type parameters

[ianlancetaylor]

This is an alternative to #61372. I mentioned it in #61372 (comment), and I'm here pulling it out into a separate proposal.

I propose that we permit using nil with type parameters. Specifically, I propose that we change the language such that

1. we can assign nil to a variable whose type is a type parameter; it sets the variable to the zero value of its type;
2. we can compare a value whose type is a type parameter to nil; this is permitted even if the type parameter is not comparable, and == reports whether the value is equal to the zero value of its type.

---

Background

#61372 aims to solve three problems:

1. Referring to a zero value in generic code. Today people suggest *new(T), which [@rsc finds] embarrasingly clunky to explain to new users. This comes up fairly often, and we need something cleaner.

2. Comparing to a zero value in generic code, even for non-comparable type parameters. This comes up less often, but it did just come up in cmp.Or (cmp: add Or #60204).

3. Shortening error returns: return zero, err is nicer than return time.Time{}, err.

The solution in #61372 is to introduce a new builtin type zero that may be used with any type that does not already have a short name for the zero value.

This proposal addresses the first two points but not the third.

---

Rationale

I'm concerned that #61372 is overfitting to the current language and creating a solution that makes sense to experienced Go programmers but not to people learning the language for the first time. We already have three names for the zero value: 0, "", nil. Introducing a fourth name, zero, makes sense given where we are but seems confusing for people learning the language for the first time.

Extending the use of zero to all types, as originally proposed and as mentioned by @robpike at #61372 (comment), permits confusion when using a variable p of pointer type: we can write both p == zero and *p == zero, but they mean very different things (as mentioned by @rsc at #61372 (comment)).

Extending the use of nil to all types somewhat exacerbates the problem address by the FAQ in Why is my nil error value no equal to nil?, which has itself been reported as a bug many times despite the FAQ entry (#43643, #44102, #47551, #53768, #54229, #56930, #57292, #59521 among many others).

Extending nil to type parameters only, as proposed here, is imperfect, but it addresses the immediate needs, and to me it seems less imperfect than the other solutions.

[willfaught]

Extending the use of zero to all types, as originally proposed and as mentioned by @robpike at #61372 (comment), permits confusion when using a variable p of pointer type: we can write both p == zero and *p == zero, but they mean very different things (as mentioned by @rsc at #61372 (comment)).

@ianlancetaylor This sort of confusion is already permitted in Go:

func F() func() *int

var _ = F() == nil
var _ = F()() == nil

Is your argument that enabling that was a mistake, and we should minimize the number of ways this sort of mistake can happen in the future?

---

Using nil in generic functions, and zero elsewhere, adds another non-orthogonal dimension to the language, increasing the language complexity between those dimensions geometrically. What is your argument for why that complexity is less than the complexity of using zero or nil everywhere?

[cespare]

Introducing a fourth name, zero, makes sense given where we are but seems confusing for people learning the language for the first time.

The proposed expansion of nil seems like it would be be even harder to explain to new Go programmers than nil already is. Now we'll be able to use nil for (for example) numeric things when they are type parameters.

Overall I don't think this proposal is an improvement over #61372 in terms of complexity, explainability, and general language coherence, but it is substantially less useful (because it doesn't change error returns).

[ianlancetaylor]

@willfaught I agree that function calls can lead to confusion with nil, but fortunately functions that return functions are much less common than pointers.

Using nil in generic functions, and zero elsewhere, adds another non-orthogonal dimension to the language,

To be clear, I'm suggesting that we not add the predeclared identifier zero.

What is your argument for why that complexity is less than the complexity of using zero or nil everywhere?

People must already use nil with various kinds of types, notably interface types. Adding type parameters to that list of types does not seem to me to be a significant increase in complexity.

[ianlancetaylor]

@cespare

The proposed expansion of nil seems like it would be be even harder to explain to new Go programmers than nil already is. Now we'll be able to use nil for (for example) numeric things when they are type parameters.

Yes.

Overall I don't think this proposal is an improvement over #61372 in terms of complexity, explainability, and general language coherence, but it is substantially less useful (because it doesn't change error returns).

The more I think about #61372 the more reluctant I am to explain why there are four different ways of writing the zero value.

[willfaught]

To be clear, I'm suggesting that we not add the predeclared identifier zero.

Thanks. I missed that.

I agree that function calls can lead to confusion with nil, but fortunately functions that return functions are much less common than pointers.

The point applies to any operation and nil-able type:

var X chan map[int]int

var _ = X == nil
var _ = <-X == nil

var Y [][]int

var _ = Y == nil
var _ = Y[0] == nil

These are just as "confusing" as p == nil vs. *p == nil.

You can make the same kind of argument for any operation at all:

var Z int

var _ = Z == 0
var _ = Z + 1 == 0

What if you forget the + 1 operation? It's the same as forgetting the * or () or <- or [0] operations.

It seems to me the issue is what if the programmer writes wrong code that still type-checks, and I would argue that we already don't guard against 99.99% of those cases.

People must already use nil with various kinds of types, notably interface types. Adding type parameters to that list of types does not seem to me to be a significant increase in complexity.

Then why not add numbers and strings to that list, for the same reason?

[jimmyfrasche]

The list of 3 problems can be reduced to 2:

1. name the zero value
2. compare against the zero value

returning zeroes is just a case of 1, though surely the most common.

I said nothing about generics because generics is not the only place these problems arise, though it's the most likely place this comes up now.

For the purposes of this argument we can divide code into three classes, which I hope are obvious enough

1. regular
2. generic
3. generated

In regular code naming zero comes up in cases where you need to write time.Time{} all over the place. Comparing against zero comes up when you have a struct containing a func so you end up having to write s.n == 0 && s.f == nil.

In generic code naming zero is much harder and comparing only works when the parameter is comparable. I think everyone gets why this is worse and why it means we should do something.

In generated code you have the same naming problem as with generic code and end up writing *new(T) and var zero T. Even if you have the type information available it's just simpler to do that than emit different code depending on the type. Even under #61372 with restrictions this would still be the case. Comparison is about the same as generic code. It's too much work to handle types that aren't comparable even if there are some that can be == nil. Under #61372 with restrictions there would need to be a check to see if you can use == zero or == *new(T).

If this proposal is accepted, generic code is fixed. It would do nothing for naming in regular or generic code but it would allow definition of

func isZero[T any](v T) bool {
  return v == nil
}

which could be used in regular/generated code to handle comparison.

But it would need to be copied around all over the place and there would still be the other problems. The only way to extend it would be to generalize nil to be the universal zero value.

This proposal would be an improvement but not a very satisfying one.

[DeedleFake]

If this proposal is accepted, I think that an IsZero[T any](T) bool function should probably be added to cmp. The Is prefix might not be necessary.

[ianlancetaylor]

@willfaught

The point applies to any operation and nil-able type:

Understood. And yet I think that people write if p == nil far more often with pointer types. I don't think we need to belabor this point. We don't agree, and that's OK.

Then why not add numbers and strings to that list, for the same reason?

Because we don't need to. There is a problem to solve for type parameters. There is no problem with numbers and strings.

[willfaught]

Understood. And yet I think that people write if p == nil far more often with pointer types. I don't think we need to belabor this point.

@ianlancetaylor What does the frequency of one vs. the other have to do with your argument that adding nil to every type would add more confusion to the language? My argument was that these "confusions" already exist in the language.

We don't agree, and that's OK.

This is not persuasive, and frankly comes across as a brush off. If you think you've identified a root cause of disagreement that can't be resolved, then explain your reasoning.

Because we don't need to. There is a problem to solve for type parameters. There is no problem with numbers and strings.

This is only restating the proposal, that zero values outside of generic contexts shouldn't be addressed. I'm trying to better understand the trade-offs of this approach vs. #61372 in terms of complexity, which I assume you think is a relevant aspect to consider.

[atdiar]

@ianlancetaylor personally I'm sympathetic to this idea. But I'm leaning more toward zero because I don't really see a type parameter as an interface but as a placeholder which has nilable types in its typeset sometimes but not always.

I think that overloading nil here would be equally confusing.

The rule that the zero value for a type parameter is nil seems assuredly easy to understand, I agree.

I think that zero should be the universal zero with some caveats in where it can be used (only assignments in order to zero out memory locations).
In that case zero isn't a fourth way to write zero values, it simply supersedes all the other ways for assignments. (but not function calls which is value passing)

Maybe that should be its own proposal I'm not sure.