I never use new(). It gives a way to allocate, that I would prefer to avoid in f...

nerdwaller · on Sept 8, 2022

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

37ef_ced3 · on Sept 8, 2022

It's used like this

  p := new(int)

since you can't say

  p := &int{}

bilinguliar · on Sept 8, 2022

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

marwatk · on Sept 8, 2022

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.

bilinguliar · on Sept 8, 2022

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.

37ef_ced3 · on Sept 8, 2022

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?

bilinguliar · on Sept 8, 2022

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.