Problem

Currently in Go, make() serves as a general instantiator for the more complex of the builtin data structures. If you want to allocate a pointer to a zero-value, on the other hand, new() is the function to use. However, while both of these functions take a type as the first argument, they do so quite differently. new(T) results in a non-nil *T, but make(T) results in a non-nil T directly. In other words, the type passed to make() is the type that it returns, while new() returns a pointer to the type that it is passed instead.

In most situations, this difference is not a particular issue, but with the introduction of generics it can cause some minor problems. For example, I recently wanted to be able to instantiate zero-values of a type that I was passed. The function, slimmed down into a contrived variant, is having trouble trying to do the following:

type Constraint interface {
  M()
}

func Example[T Constraint]() T {
  return ???
}

func main() {
  t1 := Example[ImplOne]()
  t2 := Example[*ImplTwo]()
}

In the case of the first call to Example(), I could easily just create an instance of T by doing var t T; return t, but that doesn't work for the second as it will return nil. Similarly, I can't actually use new(T) as doing so creates a pointer to the type that it is passed, so it will try to return *ImplOne for the first call and **ImplTwo for the second, which is worthless. Worse, while the first case can be manually dereferenced after the call to new(T), the second will result in returning a nil pointer, putting the whole thing back at square one.

I wound up solving the issue by writing the following function:

func deepZero[T any]() (v T) {
  t := reflect.TypeOf(v)
  if t.Kind() != reflect.Pointer {
    return v
  }
  return reflect.New(t.Elem()).Interface().(T)
}

I'm not thrilled with the need to use reflect for this solution, but it works.

Proposal

I propose to extend the make() builtin to return a non-nil zero value for non-interface types, excluding unsafe.Pointer and function types. In other words, for non-nillable types, it will simply return their regular zero value. For nillable types, on the other hand, it will return an empty, non-nil variant of whatever they represent. It already does this for slices, maps, and channels, so this proposal essentially just extends that behavior to most other concrete type.

To allow for the usage of this new behavior with generics, usage of make(T) where T is an unsafe.Pointer, function type, or interface would return nil instead of being a compile-time error. Alternatively, this could be made to panic. This would mean that some code would be unsafe despite compiling, but it would also leave the door open for the behavior to be changed later on without breaking the compatibility guarantee.

make([]T, 3) // No change.
make(map[K]V) // No change.
make(int) // Returns 0.
make(string) // Returns an empty string.
make(*int) // Returns the same thing as new(int).
make(any) // Since there is no obvious non-nil zero value for interfaces, it returns nil.
make(func()) // Also returns nil.

This would let the above function be rewritten as

func Example[T Contraint]() T {
  return make(T)
}

Concerns

One issue that I have with this is that it adds yet another way to instantiate pointers. For structs, there's already an overlap between new(T) and &T{}. I think that the benefit is worth it, though.

I'm also not thrilled with either solution to the issue of unsafe.Pointer, function types, and interfaces. I think that returning nil is probably fine, but that would mean that it would be stuck that way. I don't like the idea of it panicking, but plenty of other simple operations do that, too, such slice-to-array conversions. Those are easier to check for safety in advance at runtime, however.