Hacker News Reader

Comment by bilinguliar | Hacker News Reader

I never use new(). It gives a way to allocate, that I would prefer to avoid in favor of declaring zero-value explicitly. Maybe I am missing the point of new().

View on HN

I don't particularly find that inconsistent, though it's usage may not be super common (depending on the type of work you do in go). If you ever need to do atomic operations, it's rather helpful. Though they have been adding new features in go 1.19+ that help there (Int32[1] type, for example). As an aside, for those using atomics - Uber's wrapper library[2] is pretty pleasant to use.

[1] - https://pkg.go.dev/sync/atomic#Int32 [2] - https://pkg.go.dev/go.uber.org/atomic

It's used like this

  p := new(int)

since you can't say

  p := &int{}

Indeed, this may be the use case. I am curious how often you may need a pointer to an int.

In things like rest APIs you need them quite a bit to distinguish between a value being the zero value and not present at all. Most libraries I've seen have an IntPointer or similar function exposed globally.

This is true. In the case of REST, it is your “encoding/json” who will allocate for int pointer. So I do not see why new() is needed.

Are you seriously suggesting that the language should not have notation for allocating zeroed primitive types and receiving the address of the allocation?

  var (
      p1 = new(int)
      p2 = new(*int)
      p3 = new(**int)
      p4 = new(complex64)
      p5 = new(complex128)
  )

I feel like you must be joking. Should we say

  var (
      c complex128
      p = &c
  )

every time?

In five years, I needed to do the latter only once or twice because a library I was using demanded a pointer to a primitive. Forgive my arrogance, but why does one need a pointer to a zero-value primitive in Go? I sincerely believe there is a use case for it, but I never needed this.

Reply on news.ycombinator.com